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Shadow function box interface for use in process control network e.g. chemical 
or p froleum process has memory receiving data pertaining to external function 
block, according- to configuration protocol of internal function block 
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Abstract 



A shadow function block (108) has a communications port with an input that communicates with an external function 
block (112) via the communication network. This is done to receive data pertaining to the external function block. A 
memory (156) stores the received data pertaining to the external function block, according to a configuration protocol 
of the internal function block (152). Independent claims are also included for (1) A controller adapted to be 
communicatively coupled to a number of field devices, and (2) A method of implementing a control routine within a 
process controller. 
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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

@ Interface in Form eines Schattenfunktionsblockes fur die Verwendung in einem Prozessregelnetzwerk 

(57) Ein ProzeSkontroller, der kommunikativ mit einer exter- 
nen Bereichsvorrichtung uber ein Kommunikationsnetz- 
werk gekoppelt ist, verwendet einen Schattenfunktions- 
block, der innerhalb eiries ProzeSkontrollers angeordnet * . 

ist, um eine Implementierung einer Steuer- oder Regel- 
routine zu ermogiichen, die sowohl einen internen Funk- 
tionsblock, der innerhalb des ProzefSkontrollers angeord- 
net ist, als auch einen externen Funktiorisblock, der inner- 
halb. der externen Bereichsvorrichtung angeordnet ist, 
1 verwendet. Der Schattenfunktionsblock enthalt einen 
Kommunikationsport, der mit dem externen Funktions- 
block uber das Kommunikationsnetzwerk kommuniziert, 
um dadurch Daten, die den externen Funktionsblock be- 
treffen, zu empfangen, enthalt einen Speicher, der die 
empfangenen Daten gemafc einem Konfigurationsproto- 
koll des internen Funktionsblocks separiert, und einen 
Ausgang, der die gespeicherten externen Funktionsblock- 
daten in den internen Funktionsblock gemafc dem Konfi- 
[ gurationsprotokoll des internen Funktionsblocks liefert. 
Der Kommunikationsport des Interface-Funktionsblocks 
kann einen Ausgang enthalten, der Daten, die durch den 
Kontroller oder den internen Funktionsblock erzeugt wor- 
den sind, zu dem externen Funktionsblock unter Verwen- 
dung des Kommunikationsprotokolls sendet, welches 
dem externen Funktionsblock zugeordnet ist. 
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Beschreibung 



Die vorliegende Erfindung betrifft ProzeBregelnetzwerke 
und spezieller einen ProzeBkontroller, der Schattenfunkti- 
onsblocke verwendet, urn Informationen wiederzugeben, 
die exterhen Funktionsblocken zugeordnet sind, welche m 
einem ProzeBregelnetzwerk verteilt sind. 

ProzeBregelnetzwerke, wie beispielsweise solche, die in 
chemischen, Mineralol- oder anderen Prozessen verwendet 
werden, enthalten im aligemeinen einen zentralisierten Pro- 
zeBkontroller; der kommunikativ mit einer oder mehreren 
Gebiets- oder Bereichsvorrichtungen gekoppelt ist, die bei- 
spielsweise Ventilstellglieder, Schalter, Sensoren (wie z.B. 
Temperatur-, Druck- und Stromungsratensensoren) usw. 
sein konnen. Diese Bereichsvorrichtungen konnen Steuer- 
funktionen innerhalb des Prozesses durchfuhren (wie das 
Offhen oder SchlieBen eines Ventils), konnen Messungen 
innerhalb des Prozesses vornehmen, die fiir die Steuerung 
oder Regelung der Arbeitsweise des Prozesses verwendet 
werden, oder konnen irgendeine andere gewunschte Funk- 
uon innerhalb des Prozesses ausfuhren. ProzeBregler wur- 
den in historischer Weise an die Bereichsvorrichtungen uber 
eine oder mehrere analoge Signalleitungen oder Busse ange- 
schlossen, die beispielsweise 4-20 mA (Milliampere) Si- 
gnale zu und von den Bereichsvorrichtungen leiten. Allge- 
mein gesagt, empfangt der ProzeBkontroUer Signale, welche 
die Messungen angeben, die durch einen oder durch meh- 
rere Bereichsvorrichtungen vorgenommen wurden und/oder 
andere Informationen anzeigen, die zu einer oder zu mehre- 
ren- Bereichsvorrichtungen gehoren, und er verwendet diese 
Informationen, urn eine typische komplexe Steuerroutine zu 
implementieren, und erzeugt dann Steuersignale, die uber 
die analogen Signalbusse zu einer oder mehreren der Be- 
reichsvorrichtungen gesendet werden, urn dadurch den Be- 
trieb des Prozesses zu steuem. 

Kiirzlich kam Bewegung in die ProzeBregel- oder -steuer- 
industrie, urn bereichsbasierende digitale Kommunikatio- 
nen in der ProzeBregelumgebung zu implementieren. Bei- 
spielsweise hat die ProzeBregelindustrie eine Anzahl von of- 
fenen, digitalen oder kombinierten digitalen und analogen 
StandardkommunikationsprotokoUen entwickelt, wie bei- 
■ spielsweise die HART®, PROFIBUS®, WORLDFIP®, De- 
vice-Net® und CAN-Protokolle. Diese digitalen Kommum- 
kationsprotokolle ermoglichen es mehreren Bereichsvor- 
richtungen, an einen bestimmten Bus angeschlossen zu wer- 
den, sie unterstutzen mehrere und schnelle Kommunikatio- 
nen'zwischen den Bereichsvorrichtungen und dem Kontrol- 
ler und/oder ermoglichen es den Bereichsvorrichtungen, 
mehrere und unterschiedliche Typen von Informationen, 
wie beispielsweise Informationen, die den Status und die 
Konfiguration der Bereichsvorrichtung selbst betreffen, zu 
dem ProzeBkontroller zu senden. Femer ermoglichen es 
diese digitalen Standardprotokolle den Bereichsvorrichtun- 
gen, die von unterschiedlichen Herstellem hergestellt wur- 
den' zusarnmen mit dem gleichen ProzeBregelnetzwerk ver- 
wendet zu werden. 

Auch gibt es nunmehr Bewegung innerhalb der ProzeBre- 
gelindustrie, die ProzeBregelung oder -steuerung zu dezen- 
tralisieren, wodurch die ProzeBkontroUer vereinfacht wer- 
den. Eine dezentralisierte Steuerung oder Regelung wird da- 
durch erhalten, daB bereichsmontierte ProzeBsteuervornch- 
tungen, wie beispielsweise Ventilstellglieder, Sender usw,, 
eine oder mehrere ProzeBsteuerfunktionen durchfuhren, und 
" zwar unter Verwendung von Einrichtungen, die in typischer 
Weise als Funktionsblocke bezeichnet werden, und mdem 
dann Daten uber eine Busstruktur fur die Verwendung durch 
andere ProzeBsteuervorrichtungen (oder Funktionsblocke) 
bei der Ausfuhrung anderer Steuerfunktionen ubertragen 



werden. Urn diese Steuerfunktionen zu implementieren, ent- 4 
halt jede ProzeBsteuervorrichtung in typischer Weise einen 
Mikroprozessor mit der Fahigkeit, einen oder mehrere 
Funktionsblocke zu implementieren, als auch die Fahigkeit, 
5 mit anderen ProzeBsteuervorrichtungen zu kommunizieren, 
und zwar unter Verwendung eines offenen Standardkommu- 
nikationsprotokolls. In dieser Weise konnen Bereichsvor- 
richtungen innerhalb eines ProzeBregelnetzwerks miteinan- 
der verbunden werden, urn miteinander zu kommunizieren 
10 und urn eine oder mehrere ProzeBsteuerfunktionen unter 
Bildung einer Regelschleife durchzufuhren, und zwar ohne 
Einschreiten eines zentralisierten ProzeBkontrollers. Das ge- 
samtdigitale Zweidraht-Busprotokoll, welches durch die 
Fieldbus Foundation entworfen wird, bekannt als FOUN- 
15 DATION (eingetragene Marke) Fieldbus- (im folgenden als 
"Fieldbus" bezeichnet) Protokoll bekannt ist, ist ein offenes 
KommunikationsprotokoU, welches es den Vorrichtungen, 
die von unterschiedlichen Herstellem stammen, ermoglicht, 
untereinander zusammenzuarbeiten und zu kommunizieren, 
20 und zwar uber einen Standardbus, um eine dezentralisierte. 
Steuerung innerhalb es Prozesses zu bewirken. 

Da digitale Kornmunikationsprotokolle und dezentrali- 
sierte Steuerungsschemata (wie solche, die in der Fieldbus- 
Steuer- oder -Regelumgebung verwendet werden) so neu. 
25 sind, verwenden Prozesse, welche diese Protokolle imple- 
mentieren, diese lediglich in einem eingeschrankten Aus- 
maB. Als ein Ergebnis unterstutzen neuere ProzeBkontroller, 
wie der Delta V- (eingetragene Marke) ProzeBkontroller, der 
durch Fisher-Rosemount Systems hergestellt wird, sowohl 
30 analoge als auch digitale Kornmunikationsprotokolle und es 
- kann eine Hardware so programmiert werden, um die Steue- 
rung in einem.ProzeB zu implementieren, der Bereichsvor- 
richtungen enthalt, die unter -Verwendung von analogen 
Standardprotokollen kommunizieren, wie beispielsweise ei- 
35 nem 4-20 mA Protokoll, und unter Verwendung von einem 
oder mehreren neueren digitalen Protokollen, wie dem 
Fieldbus-Protokoll. 

Es stellten sich jedoch Probleme ein, wenn versucht 
wurde, die Steuerung von analogen und digitalen Bereichs- 
40 vorrichtungen zu integrieren, und zwar speziell bei den 
Fieldbus-Bereichsvorrichtungen in einem ProzeBregelnetz- 
werk, welches einen zentralisierten Kontroller verwendet. 
Da die Steuerfunktionen fiir analoge Bereichsvorrichtungen 
X und einige digitale Bereichsvorrichtungen innerhalb des 
45 zentralisierten ProzeBkontrollers implementiert sind, wer- 
den alle erforderhchen Informationen uber diese Bereichs- 
vorrichtungen innerhalb des zentralisierten ProzeBkontrol- 
ler s.empfangen und gespeichert. Dies macht es seinerseits 
moglich, daB der zentralisierte ProzeBkontroller die Steue- 
50 rung unterschiedlicher analoger und digitaler Bereichsvor- 
richtungen integriert, die die momentane Konfiguradon und 
Zustand von Abschnitten des ProzeBregelnetzwerks dar- 
steUt, in welchem diese Vorrichtungen gelegen sind, um An- 
derungen in der ProzeBregelnetzwerkkonfiguration in bezug 
55 auf diese Vorrichtungen usw. vorzunehmen. Wenn jedoch 
ein dezentralisiertes Steuerschema, wie beispielsweise das 
Fieldbus-Steuerschema in einem Teil des Prozesses verwen- 
det wird, braucht der zentralisierte ProzeBkontroller keinen 
direkten Zugriff mehr auf all die lauf enden Informationen zu 
60 haben, die durch die ProzeBsteuervorrichtungen verwendet 
werden oder diesen zugeordnet sind, die der dezentralisier^ 
ten Steuerung unterworfen sind. Tatsachlich sind einige de- 
zentralisierte ProzeBsteuerprotokolle, wie beispielsweise 
das Fieldbus-Protokoll,-spezifisch so ausgelegt, daB es nicht 
65 erforderlich ist, Informationen zu einem zentralisierten Pro- 
zeBkontroUer auf einer regularen Grundlage zu senden. 
Diese Tatsache macht es fur den zentralisierten ProzeBkon- 
troller schwierig, die Steuerung von analogen oder anderen 
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digitalen Bereichsvorrichtungen mit den Bereichsvorrich- 
tungen zu integrieren, die der dezentralisierten Steuerung 
unterworfen sind. Es macht es auch fur den zentralisierten' 
ProzeBkontroller ischwierig, den laufenden oder momenta- 
nen Zustand der Vorrichtungen als Modell nachzubilden ' 5 , 
oder darzustellen, die der dezentralisierten Steuerung unter- 
worfen sind, oder dies inherhalb eines dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks durchzufiihren. 

Tatsachlich miissen fur den zentralisierten ProzeBkontrol- 
ler, der die Informationen von dem dezentralisierten Steuer- 10 
abschnittdes ProzeBregelnetzwerks empfangt, die Bereichs- 
vorrichtungen (oder Funktionsblocke) innerhalb dieses Ab- 
schnitts des Prozesses spezifisch konfiguriert sein, um Infor- 
mationen direkt zu dem zentralisierten ProzeBkontroller zu 
senden (was bedeutet, daB der zentralisierte ProzeBkontrol- 15 
ler all diese Informationen empfangen und handhaben muB, 
wobei der groBte Teil derselben fur die Betriebs weise des 
zentralisierten ProzeBkon trailers nicht erforderlich ist). Al- 
ternate v muB der zentralisierte ProzeBkontroller aktiv anfra- 
gen, um die von ihm. benotigten Informationen zu empfan- 20 
gen. Da .soldi einer Anfrage keine hdhere Prioritat in bei- 
spielsweise dem Fieldbus-Protokoll gegeben wird, und zwar 
zu der Zeit, in der der zentralisierte ProzeBkontroller die an- 
gefragten Informationen empfangt, konnen diese Informa- 
tion veraltet sein. Es ist ferner fiir den zentralisierten Pro- 25 
zeBkontroller schwierig, wenn nicht unmoglich, Daten an- 
zufragen und zu empfangen, die zu einer spezifizierten Zeit 
oder Zeitpuhkt aktiv oder momentan vorhanden sind. Statt 
dessen empfangt der zentralisierte ProzeBkontroller ledig- 
lich die Daten zu dem Zeitpunkt, zu welchem die Anfrage 30 
die Bereichsvorrichtung erreicht. Dariiber hinaus ist die 
Kommunikation zwischen dem zentralisierten ProzeBkon- 
troller und den Bereichsvorrichtungen innerhalb des dezen- 
tralisierten Abschnitts des Prozesses hoch spezialisiert und 
erfordert ein betrachtliches Wissen iiber das dezentralisierte 35 
Steuerprotokoll, was es fur den Konstrukteur oder Entwick- 
ler der zentralisierten ProzeBsteuerroutine schwierig macht, 
diese Kommunikation auf einer gewurischten Basis zu im- 
plementieren. 

Die vorliegende Erfindung zielt auf die Verwendung von 40 
Schattenfunktionsblocken ab, um in einem zentralisierten 
ProzeBkontroller die Steuerung der Funktionsblocke, die in 
dem zentralisierten Kontroller vorheirschen, mit solchen zu 
integrieren, die in einer externen Vorrichtung vorherrschen, 
wie beispielsweise einer Bereichsvorrichtung. Die vorlie- 45 
gende Erfindung kann auch dafur verwendet werden, einem 
Kontroller die Moglichkeit zu geben, Vorrichtungen oder 
Funktionsblocke zu steuem oder mit diesen zu kommunizie- 
ren, die in' eiriem Kommunikationsnetzwerk gelegen sind 
oder die ein Kommunikationsprotokoll verwenden, welches 50 
von demjenigen verschieden ist, welches der Kontroller ver- 
wendet. Speziell wird ein Schattenfunktionsblock in dem 
zentralisierten Kontroller erstellt oder eingerichtet, um die 
Daten, die einem externen Funktionsblock zugeordnet sind, 
der in einer externen Vorrichtung, wie beispielsweise einer 55 
Bereichsvorrichtung, gelegen ist, zu spiegelri, und zwar in 
Eiriklang mit eiriem dezentralisierten Steuer- und Kommu- 
nikationsprotokoll, Die Steuerroutine des zentralisierten 
Kontrollers kommuniziert mit dem externen Funktionsblock 
ubei* den Schattenfunktionsblock, so als ob der exteme 60 
Funktionsblock durch den zentralisierten Kontroller imple- 
mentiert ware. Der Schattenfunktionsblock erhalt automa- 
tisch die momentanen Informationen, die dem externen 
Funktionsblock zugeordnet sind, und sendet Befehle zu dem 
externen Funktionsblock unter Verwendung des Protokolls, 65 
welches dem externen (z. B. dezentralisierten) Steuerproto- 
koll zugeordnet ist. Im Falle eines Fieldbus-Protokolls. wird 
diese Kommunikation unter Verwendung von sowohl syn- 



chronen als auch asynchronen Kommunikationen erreicht. 
Jedoch kommuniziert der Schattenfunktionsblock mit ande- 
ren Funktionsblocken innerhalb des zentralisierten Kontrol- 
lers so, als ob der externe Funktionsblock vollstandig durch 
den zentralisierten Kontroller implementiert ware. 

Unter Verwendung des Schattenfunktionsblockes der vor- 
liegenden Erfindung kann die zentralisierte ProzeBsteuer- 
routine auf den neuesten Stand gebrachte Informationen um 
den tatsachlichen Funktionsblock herum in einer Realzeit 
oder nahezu auf Realzeitbasis empfangen, da diese Informa- 
tionen in dem Schattenfunktionsblock gespiegelt werden, 
der immer fur die zentralisierte ProzeBsteuerroutine zugang- 
lich ist. In ahnlicher Weise kann die zentralisierte ProzeB- 
steuerroutine Befehle zu dem tatsachlichen Funktionsblock 
dadurch senden, indem sie einen Befehl zu dem Schatten- 
funktionsblock ungeachtet des Typs oder der Lage der Vor- 
richtung sendet, in welcher der tatsachliche Funktionsblock 
gelegen ist. Der Schattenfunktionsblock setzt dann diesen 
Befehl unmittelbar in Verbindung zu dem tatsachlichen 
Funktionsblock unter Verwendung geeigneter Komrnunika- 
tionsbefehle, die dem dezentralisierten ProzeBsteuerproto- 
koll zugeordnet sind. Auf diese Weise braucht die zentrali 1 
sierte ProzeBsteuerroutine keine signifikante Datenbasis- 
steuerung in bezug auf die Bereichsvorrichtungen durchzu- 
fiihren, und zwar innerhalb des dezentralisierten Steuerab- 
schnitts des Prozesses, da die Informationen, die sie fur die 
Bereichsvorrichtungen innerhalb des dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks, in dem Schattenfunkti- 
onsblock bzw. den Schattenfunktionsblocken gelegen sind. 
In ahnlicher Weise braucht die zentralisierte ProzeBsteuer- 
routine nicht spezifische programmiert zu werden, um mit 
den komplexen und fordernden Aufgaben der. Kommunika- 
tion in dem dezentralisierten ProzeB steuerprotokoll fertig zu 
werden, da diese Kommunikation automatisch durch den 
Schattenfunktionsblock durchgefuhrt wird. 

GemaB einem Aspekt der vorliegenden Erfindung ist ein 
Interface oder Schattenfunktionsblock dafur ausgebildet, 
um in einem ProzeBkontroller verwendet zu werden, der 
kommunikativ mit einer externen Vorrichtung iiber ein 
Kommunikationsnetzwerk gekoppelt ist, um dem ProzeB- 
kontroller die Moglichkeit zu geben, eine Steuerroutine un- 
ter Verwendung von sowohl dem internen Funktionsblock, 
der in dem ProzeBkontroller vorherrscht, als auch eines ex- 
ternen Funktionsblockes, der innerhalb der externen Vor- 
richtung vorhanden ist, zu implementieren. Das Interface 
oder der Schattenfunktionsblock gemaB diesem Aspekt der 
Erfindung enthalt einen Kommunikationsport mit einem 
Eingang, der mit dem externen Funktionsblock iiber das 
Kommunikationsnetzwerk kommuniziert, um dadurch Da- 
ten zu empfangen, die zum externen Funktionsblock, geho- 
ren, und enthalt einen Speicher, der die empfangenen Daten, 
die zu dem externen Funktionsblock gehoren, gemaB einem 
Konfigurationsprotokoll des internen Funktionsblockes 
speichert. Wenn es erwunscht ist, kann der Interface- Funk- 
tionsblock auch einen Ausgang aufweisen, der die gespei- 
cherten externen Funktionsblockdaten zu dem internen 
Funktionsblock liefert, und zwar unter Verwendung .des 
Konfigurationsprotokiolls des internen Funktionsblocks. In 
annlicher Weise kann der Kommunikationsport des Inter- 
face-Funktionsblocks einen Ausgang enthalten, der Daten 
(wie beispielsweise verkettete Daten oder Befehle) zu dem 
externen Funktionsblock sendet, und zwar unter Verwen- 
dung eines Kommunikationsprotokolls, welches dem exter- 
nen Funktionsblock zugeordnet ist. 

In bevorzugter Weise empfangt der Kommunikationsport 
des Interface-Funktionsblocks die Daten, die zu dem exter- 
nen Funktionsblock gehoren, unabhangig von der Operation 
der internen Funktionsblocke. In ahnlicher Weise kommunir 
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ziert bei einer Ausfuhrungsform der externe Funktionsblock 
fiber das Kommunikationsnetzwerk unter Verwendung ernes 
ersten Kommumkationsprotokolls, welches verschieden ist 
von einem zweiten Konrniunikationsprotokoll, welches dem 
internen Funktionsblock zugeordnet ist, und in diesem FaU 
kommuniziert der Kommunikationsport mit dem extemen 
Funktionsblock unter Verwendung des ersten Kommunika- 
tionsprotokolls und der Ausgang des Interface-Funktions- 
blocks kommuniziert mit dem intemen Funktionsblock ge- 
' maB dem zweiten Kommunikationsprotokoll. 

Wenn es gewiinscht wird, kann das erste Kommunikati- 
onsprotokoll, welches dem extemen Funktionsblock zuge- 
ordnet ist, ein Fieldbus-Kommunikationsprotokoll sein. In 
diesem Fall kann der Kommunikationsport eine Interface- 
vorrichtung (wie beispielsweise eine Interfacekarte) ver- 
wenden, die dafiir konfiguriert ist, urn mit der extemen Vor- 
richtung unter Verwendung des Fieldbus-Kommunikations- 
protokolls zu kommunizieren, um dadurch eine Kommuni- 
kation mit dem extemen Funktionsblock vorzunehmen. Der 
Kommunikationsport kann beispielsweise mit dem externen 
Funktionsblock unter Verwendung synchroner Kommunika- 
tionen kommunizieren, wie beispielsweise die Herausgeber- 
/Teilnehmerbeziehungen des Fieldbus-Kommunikations- 
protokolls und/oder kann asynchrone Kommunikationen 
verwenden, wie z. B. die Betrachtungsobjekte in dem Field- 
bus-Kommunikationsprotokoll. AUgemeiner kann die ex- 
terne Vorrichtung unter Verwendung eines Vorrichtungs- 
Kommunikationsprotokolls kommunizieren, welches die 
Kommunikation der logisch verketteten Pakete an Daten un- 
ter Verwendung von standardisierten Kommunikationsrufen 
unterstiitzt, wie beispielsweise die Betrachtungsobjekte und 
die Betrachtungswamungen des Fieldbus-Kommunikati- 
onsprotokolls, und es kann der Kommunikationsport mit 
dem extemen Funktionsblock unter Verwendung der stan- 
dardisierten Kommunikationsmfe kommunizieren. In ahnli- 
cher Weise kann der Kommunikationsport Alarmanzeigen 
von dem extemen Funktionsblock empfangen und kann 
diese Alarmanzeigen in dem Speicher fur die Verwendung 
durch den Kontroller speicherm 

GemaB einem anderen Aspekt der vorliegenden Erfin- 
dung enthalt ein Kontroller, der dafiir geeignet ist, um kom- 
munikativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, einen Speicher und eine Steuerroutine 
enthalten, die in dem Speicher abgespeichert ist und die 
durch den Prozessor implementiert ist, um die Vielzahl der 
Bereichsvorrichtungen zu steuern. Die Steuerroutine enthalt 
eine Vielzahl von miteinander verbundenen intemen Funk- 
tionsblocken, die unter Verwendung eines Kontrollerproto- 
koUs. konfiguriert sind, so daB sie durch den Kontroller im- 
plementiert werden, und kann einen Interface-Funktions- 
block enthalten, der mit einem der miteinander verbundenen 
intemen Funktionsblocken kommuniziert, unter Verwen- 
dung des Kontrollerprotokolls und der mit einem extemen 
Funktionsblock kommuniziert, der in einer extemen Be- 
reichsvorrichtung vorhanden ist, und zwar unter Verwen- 
dung eines Bereichsvorrichtungs-Kommunikationsproto- 
kolls. Der Interface-Funktionsblock speichert Daten, die zu 
dem extemen Funktionsblock gehoren und von dem exter- 
nen Funktionsblock fur die Verwendung durch die Steuer- 
routine empfangen werden. 

GemaB einem weiteren Aspekt der vorliegenden Erfin- 
dung speichert ein Verfahren zum Implementieren einer 
Steuerroutine innerhaib eines ProzeBkontrollers, innerhalb 
des Kontrollers eine Vielzahl von miteinander verbundenen 
intemen Funktionsblocken, die gemaB einem Kontrollerpro- 
tokoU konfiguriert sind, um einen Teil der Kontrollerroutine 
zu implementieren. Das Verfahren erzeugt auch innerhalb 
des Kontrollers einen Interface-Funktionsblock, der gemaB 



dem Kontrollerprotokoll konfiguriert. ist, der jedoch mit ei- 
nem extemen Funktionsblock kommuniziert, der in einer 
extemen Bereichsvorrichtung gelegen ist, und zwar unter 
Verwendung eines Vorrichtungs-Kommunikationsproto- 
5_ kolls, welches der extemen Vorrichtung zugeordnet ist. Das 
Verfahren erzeugt dann eine Steuerroutine, welche die Viel- 
zahl der miteinander verbundenen intemen Funktionsblocke 
und den Interface-Funktionsblock verwendet, um den Pro- 
zeB zu steuern oder zu regeln und wahrend der Implementie- 
.10 rung der Steuerroutine werden Daten gespeichert, die dem 
extemen Funktionsblock zugeordnet sind und von diesem 
empfangen werden, und zwar in dem Interface-Funktions- 
block fur die Verwendung durch die Steuerroutine, so als ob 
der exteme Funktionsblock durch den Kontroller als einer 
15 der intemen Funktionsblocke implementiert ware. 

Das Verfahren kann einem Anwender auch erlauben, die 
Steuerroutine dadurch zu konfigurieren, indem jeder eine 
Anzahl von Funktionsblocken, die in der Steuerroutine ver- 
wendet werden sollen, spezifiziert wird, die Verbindungen . 
20 zwischen den spezifizierten Funktionsblocken, die in der 
Steuerroutine zu verwenden sind, identiflziert werden und 
die Stelle oder Ort eines bestirnmten spezifizierten Funk- 
tionsblockes spezifiziert wird, und zwar als ein interner 
Funktionsblock, der in dem Kontroller implementiert ist, 
25 oder als ein externen Funktionsblock, der durch eine Be- 
reichsvorrichtung implementiert ist. In dem Fall, bei wel- 
chem ein Funktionsblock in einer extemen Vorrichtung zu 
implementieren ist, enthalt das Verfahren den Schritt gemaB 
einer Auswahl einer extemen Vorrichtung aus einer Liste 
30 oder einem Satz von Vorrichtungen, die in dem System ver- 
bunden oder angeschlossen sind. . 

Fig. 1 ist ein schematisches Blockschaltbild eines bei- 
spielhaften ProzeBregelnetzwerks, welches zentralisierte 
und dezentralisierte ProzeBsteuerabschnitte darin enthalt; 
35 Fig; 2 ist ein schematisches Blockschaltbild von drei 
Standardfunktionsblocken, die einer oder mehreren Field- 
bus-Bereichsvorrichtungen zugeordnet sind; 

Fig- 3 ist ein Zeitsteuerschema fur einen Makrozyklus ei- 
nes Segments eines Fieldbus-Busses, der innerhalb des Pro- 
40> zeBregelnetzwerks von Fig. 1 gelegen ist; 

Fig. 4 ist ein schematisches Blockschaltbild, welches die 
Verbindung eines Schattenfunktionsblockes mit anderen 
Funktionsblocken herausgreift, die einer zentralisierten Pro- 
zeBsteuerroutine zugeordnet sind und innerhalb eines zen- 
45 tralisierten ProzeBkontrollers gelegen sind; 

Fig. 5 ist ein Blockdiagramm eines Teiles eines ProzeBre- 
gelsystems unter Verwendung des Schattenfunktionsblockes 
der vorliegenden Erfindung; 

Fig. 6 ist ein RuBdiagramm, welches die Installation ei- 
50 nes Steuermoduls innerhalb des Kontrollers von Fig. 1 ver- 
anschaulicht; 

Fig. 7 ist ein RuBdiagramm, welches die Installation ei- 
nes aktiven Verbindungsgliedplans in dem Fieldbus-Ab- 
schnitt des ProzeBregelnetzwerks von Fig. 1 veranschau- 
55 licht; 

Fig. 8 ist ein RuBdiagramm, welches die Installation von 
Veroffenthcher-Bindegliedern in dem Fieldbus-Abschnitt 
des ProzeBregelnetzwerks von Fig. 1 veranschaulicht; 
Fig. 9 ist ein RuBdiagramm, welches' die Installation ei- 
60 ner Vorrichtungskonfiguration in einer Vorrichtung inner- 
halb des Fieldbus-Abschnitts des ProzeBregelnetzwerks von 
Fig. 1 Veranschaulicht; 

Fig. 10 ist ein RuBdiagramm, welches die Installation ei- 
nes Funktionsblockes innerhalb einer Vorrichtung in dem 
65 Fieldbus-Abschnitt des ProzeBregelnetzwerks von Fig. 1 
veranschaulicht; m 

Fig. 11 ist ein FluBdiagrarnm, welches die Betriebsweise 
des Funktionsblocks und darauf bezogener Komponenten 



DE 199 40 230 A 1 



8 



wahrend des Betriebs eines zentralisierten Steuermoduls 
veranschaulicht, und zwar unter Verwendung des Schatten- 
funktionsblockes; und 

Fig. 12 ist ein RuBdiagramm, welches die Kommunika- 
tion von Daten und von Schreibanfragen von einem Block in 
einem zentralisierten Kontroller oder einem Anwender zu 
einem, externen Funktionsblock in einer Bereichsvorrich- 
tung unter Verwendung des Schattenfunktionsblockes der 
Erfindung veranschaulicht. 

GemaB Fig. 1 ist ein ProzeBregelnetzwerk 10 in Block- 
diagrammform veranschaulicht. Das ProzeBregelnetzwerk 
10 enthalt einen zentralisierten PrbzeBkontroller 12, der eine 
ProzeBsteuerroutine, die in diesem gespeichert ist, imple- 
mentieren kann. Der Kontroller 12 kann, um hier lediglich 
ein Beispiel zu nennen, der DeltaV (eingetragene Marke) 
Kontroller sein, der durch Fisher-Rosernoiint Systems ver- 
trieben wird, und kann an verschiedene Workstations, wie 
beispielsweise Personalcomputer (PCs)' 14 iiber einen Hub 
16 und Ethernet- Verbindungen 18 verbunden sein. In dieser 
Konfiguration konnen die PCs 14 durch eine oder mehrere 
Bedienungspersonen oder Anwender verwendet werden, um 
mit dem ProzeBkontroller 18 eine Kommunikation herzu- 
stellen, um dadurch Informationen zu erhalten, die das Pro- 
zeBregelnetzwerk 10 betreffen, um den Status des ProzeBre- 
gelnetzwerks 10 zu uberblicken oder zu andern, um Infor- 
. mationen zu erhalten, die die einzelnen Bereichsvorrichtun- 
gen innerhalb des ProzeBregelnetzwerks 10 betreffen usw. 
Wenn der Kontroller 12 aus einem DeltaV- Kontroller be- 
steht, kann er einen graphischen Ausschnitt der ProzeB- 
steuer- oder -regelroutine innerhalb des Kontrollers 12 zu 
dem Anwender liefern, und zwar uber einen der PCs 14, wo- 
bei die Funktionsblocke oder Steuerblocke innerhalb der 
ProzeBsteuerroutine veranschaulicht werden und auch die 
Art, in welcher diese Funktionsblocke miteinander verkettet 
sind, um die Steuerung oder Regelung eines Prozesses zu 
bewirken. Der Anwender hat die Moglichkeit, die ProzeB- 
steuer- oder -regelroutine zu andern, und zwar innerhalb des 
zentralisierten ProzeBreglers 12, indem er den graphischen 
Ausschnitt der Funktionsblocke innerhalb der Steuer- oder 
Regelroutine manipuliert, um Funktionsblocke von dieser 
Steuerroutine . wegzulassen oder zu dieser hinzuzufugen 
und/oder den Weg zu andern, in welchem die Funktions- 
blocke, die der Steuerroutine zugeordnet sind, verkettet 
sind, das heiBt den Weg oder die Art, in welcher sie verbun- 
den sind. 

Wie in Fig. 1 dargestellt ist, ist der zentralisierte Kontrol- 
ler 12 mit zahlreichen Bereichsvorrichtungen (field devices) 
verbunden, die uber einen ProzeB hinweg verteilt gelegen 
sind (allgemein durch das Bezugszeichen 19 angezeigt) . 
Der zentralisierte Kontroller 12 kanri uber irgendwelche 
Standardtypen I/O-Karten 20 und 22 mit den Bereichsvor- 
richtungen 26, 28, 30, 32, 34 und 36 kommunizieren, die der 
zentralisierten Steuerung von dem Kontroller 12 unterwor- 
fen sind. Die I/O-Karte 20 kann beispielsweise eine.analoge 
I/O-Karte sein, die den Kontroller 12 mit analogen Be- 
reichsvorrichtungen 24 und 26 verbindet, die uber 4-20- 
mA-Busse 38 kommunizieren. In ahnlicher Weise kann die 
I/O-Karte 22 eine digitale oder kombinierte digitale und 
analoge I/O-Karte sein, die mit digitalen oder gemischten 
digitalen und analogen Bereichsvorrichtungen in irgendei- 
nem gewiinschten Format kommuniziert, inklusive bei- 
spielsweise dem 4-20-mArAnalogformat oder irgendeinem 
bekannten oder standardisierten Digitalformat. Natiirlich 
konnen .die Bereichsvorrichtungen 26, 28, 30, 32, 34 und 36 
von. irgendeinem gewiinschten Typ von Bereichsvorrichtun- 
gen bestehen, beispielsweise aus Sendern, Sensoren, Ventil- 
stellgliedern, Ventikteuervorxichtungen usw. Es sei in Ver- 
bindung mit dem Beispiel des in Fig. 1 veranschaulichten 



ProzeBregelnetzwerks 10 darauf hingewiesen, daB die Be- 
reichsvorrichtungen 26-36 Abschnitten des Prozesses 19 
zugeordnet sind, die einer zentralisierten Steuerung durch 
die Steuerroutine innerhalb des Kontrollers 12 unterworfen 
5 sind. 

Der Kontroller 12 ist ebenfalls kommunikativ mit einer 
Interfacekarte 40 verbunden, die ihrerseits mit (oder Teil ist 
von) einem extemen ProzeBregelnetzwerk, in welchem die 
ProzeBregelung in einer verteilten Weise durchgefuhrt wird, 

10 oder welcher Vorrichtungen enthalt, die Funktionsblocke 
haben, die unter Verwendung eines Kommunikationsproto- 
kolls kommunizieren, welches verschieden ist von demjeni- 
gen, welches innerhalb des Kontrollers 12 verwendet wird. 
Bei der in Fig. 1 veranschaulichten Ausfuhrungsform ent- 

15 halt der dezentralisierte ProzeBsteuerabschnitt des Prozesses 
19 die Interfacekarte 40, einen Bus 42 und zahlreiche Be- 
reichsvorrichtungen 43, 44, 46, 48 und 50, die an den Bus 42 
angeschaltet sind. Das verteilte ProzeBregelnetzwerk von 
Fig. 1 kann beispielsweise ein Fieldbus-Netzwerk sein, wel- 

20 ches das Fieldbus-Kommunikationsprotokoll verwendet 
Wie im folgenden noch mehr in Einzelheiten erlautert wer- 
den wird, kann die Interfacekarte 40 eine aktive Verbin- 
dungsglied-Ablaufsteuerung sein, die dem Fieldbus-Kom- 
munikationsprotokoll zugeordnet ist. 

25 Die zentralisierte ProzeBsteuerroutine, die innerhalb des 
. Kontrollers 12 gelegen ist, empfangt EingangsgroBen von 
den Bereichsvorrichtungen 26-36 und moglicherweise 
43-50, fuhrt Berechnungen und andere Aktivitaten durch, 
die mit der Steuerroutine verbunden sind, und sendet dann 

30 Befehle zu deri Bereichsvorrichtungen iiber die I/O-Karten 
.20 und 22 und die Interfacekarte 40, um irgendeine . ge- 
wunschte Steuerung oder Regelung des Prozesses 19 zu im- 
plementieren. Es sei jedoch darauf hingewiesen, daB der de- 
zentralisierte ProzeBsteuer- oder -regelabschnitt des ProzeB- 

35 regelnetzwerks 10 (das heiBt derjenige, der dem Bus 42 in 
Fig. 1 zugeordnet ist) seine eigene ProzeBsteuerroutine in 
einer dezentralisierten Weise implementieren kann, wie dies 
hier noch beschrieben wird, und zwar in Verbindung mit der 
Steuerung, die durch den Kontroller 12 ausgefuhrt wird. 

40 Wahrend somit der Kontroller 12 mit einer Steuerung ge- 
koppelt sein kann und eine gewisse Steuerung uber die Vor- 
richtungen 43-50, die an deri Bus 42 angeschlossen sind, 
ausfuhren 1 kann, konnen diese Vorrichtungen auch Steuer- 
funktionen implementieren oder Funktionsblocke, die mit 

45 der Steuerung verbunden sind, welche durch den Kontroller 
12 implemenuert wird, die jedoch statt dessen iiber die Vor- 
richtungen, die an den Bus 42 angeschlossen sind, verteilt 
sind. 

' Wahrend bei der bevorzugten Ausfuhrungsform der de- 

50 zentralisierte Abschnitt des ProzeBregelnetzwerks 10 das 
Fieldbus-Kommunikations- und -Steuerprotokoll verwen- 
det, kann irgendein anderes oder gewiinschtes Protokoll 
ebenso verwendet werden, inklusive den Protokollen, die in 
der Zukunft entwickelt werden. Ferner kann der Schatten- 

55 funktionsblock, der hier offenbart ist, dazu verwendet wer- 
den, um eine Kommunikation zwischen irgendwelchen zwei 
unterschiedlichen Steuer- oder Kommunikationsprotokollen 
durchzufuhren, und es liegt keine Beschrankung auf die Ver- 
wendung zwischen einer zentralisierten Steuerroutine und 

60 einem dezentralisierten Steuer- oder Regelnetzwerk, wie 
beispielsweise auf eines, welches das Fieldbus-Protokoll 
verwendet, vor. Es kann beispielsweise zwischen zwei un- 
terschiedlichen zentralisierten Steuerroutinen oder Proto- 
kollen, die Steuerblocke ehthalten, verwendet werden. Mit 

65 anderen Worten ist der hier beschriebenen Schattenfunkti- 
. onsblock nicht darauf beschrankt, mit Funktionsblocken in 
dem Fieldbus-Protokoll verwendet zu werden oder sogar 
mit einem Protokoll, welches einer dezentralisierten Steuer- 



DE 199 40 230 A 1 



10 



routine zugeordnet ist, sondern kann auch dazu verwendet 
werden, einen Kontroller (oder andere Vorrichtung) dazu zu 
befahigen, mit irgendeiner anderen externen Vorrichtung zu 
kommunizieren, die irgendeinen unterschiedlichen Typ ei- 
nes Kommunikationsprotokolls verwendet. 5 

Bevor Einzelheiten des Schattenfunktionsblockes der 
Vorliegenden Erfindung erlautert werden und die Art, in 
welcher der zentralisierten ProzeBkontroller 12 solch einen 
Schattenfunktionsblock verwendet, um eine Steuerung in ei- 
nem ProzeBregelnetzwerk zu irnplementieren, folgt eine all- 10 
gemeine Beschreibung des Fieldbus-Protokolls, der Be- 
reichsvorrichtungen, die gemaB diesem Protokoll konfigu- 
riert sind, und die Art, in welcher die Kommunikation in 
dem Abschnitt des ProzeBregelnetzwerks 10 erfolgt, der das 
Fieldbus-Protokoll verwendet. Es sei darauf hingewiesen, 15 
daB, obwohl des Fieldbus-Protokoll bereits ein relativ neues 
gesamtdigitales Komrnunikationsprotokoll ist, welches fur 
die.Verwendung in einem ProzeBregelnetzwerk entwickelt 
wurde, dieses Protokoll auf dem Gebiet bekannt ist und in 
Einzelheiten in vielerlei Artikeln, Broschiiren und Beschrei- 20 
bungen beschrieben ist, die veroffentlicht, verteilt und von 
der Fieldbus Foundation unter anderem verfugbar sind, ei- 
ner nicht auf Profit basierenden Organisation, die ihren Sitz 
in Austin, Texas, hat. Speziell ist das Fieldbus-Protokoll und 
die Art der Kommunikation mit und die Art der Speicherung 25 
von Daten in Vorrichtungen, die das Fieldbus-Protokoll ver- 
wenden, in Einzelheiten in den Bedienungsanleitungen be- 
schrieben, mit demTitel "Communications Technical Speci- 
fication" und "User Layer Technical Specification" von der 
Fieldbus Foundation. 30 

Allgemein gesagt, besteht das Fieldbus-Protokoll aus ei- 
nem insgesamt digitalen, seriellen Zweiwege-Kommunika- 
tionsprotokoll, welches eine standardisierte physikalische 
Schnittstelle fur eine Zweidrahtschleife oder Bus schafft, die 
"Feld"-Ausrustungen, wie beispielsweise Sensoren, Stell- 35 
glieder, Kontroller, Ventile usw., miteinander verbindet, die 
in einer MeBgerateausriistung oder einer ProzeBsteuer- oder 
-regelumgebung gelegen sind, beispielsweise in einer Fa- 
brik oder Ahlage. Das Fieldbus-Protokoll betrifft im Prinzip 
ein ortliches Bereichsnetzwerk fur BereichsmeBgerate (Be- 40 
reichsvorrichtungen) innerhalb eines Prozesses, welches 
&ese Bereichsvorrichtungen dazu befahigt, Steuerfunktio- 
nen an Stellen auszufuhren, die uber eine ProzeBeinrichtung 
hinweg verteilt sind, und mit einer anderen zu kommunizie- 
ren, vor und nach der Ausfuhrung dieser Steuerfunktionen, 45 
um eine Gesamtsteuer- oder -regelstrategie zu realisieren. 
Da das Fieldbus-Protokoll es den Steuerfunktionen ermog- 
licht, uber ein ProzeBregelnetzwerk hinweg verteilt zu sein, 
reduziert es die Arbeitslast des zentralisierten ProzeBkon- 
trollers fur diese Bereichsvorrichtungen oder fiir die Berei- 50 
che des Prozesses. 

Ein ProzeBsteuer- oder -regelnetzwerk, welches das 
Fieldbus-Protokoll verwendet, kann einen Host enthalten, 
der mit einer Anzahl von anderen Vorrichtungen verbunden 
ist, wie beispielsweise logischen Programmkontrollern, an- 55 
deren Hostvorrichtungen und Bereichsvorrichtungen (field 
devices) uber eine Zweidraht-Fieldbus-Schleife oder -Bus, 
wie beispielsweise den Bus 42 von Fig. 1 . Der Fieldbus-Bus 
' kann unterschiedliche Abschnitte oder Segmente enthalten, 
die durch Bruckenvorrichtungen getrennt sind, wobei jeder 60 
Abschnitt des Busses einen untergeordneten Satz der Vor- 
richtungen verbindet, die an den Bus angebracht sind, um 
Kommunikationen zwischen den Vorrichtungen in einer 
Weise zu ermoglichen, wie sie im folgenden beschrieben 
wird. In typischer Weise ist eine Konfiguriervorrichtung in 65 
einer der. Vorrichtungen gelegen, wie beispielsweise einem 
Host, und ist fur die Einrichtung oder Konfigurierung jeder 
der Vorrichtungen verantwortlich (die "Smart" -Vorrichtun- 



gen insofern sind, als sie jeweils einen Mikroprozessor ent- 
halten, der eine Kommunikation durchfuhren kann und in 
einigen Fallen Steuerfunktionen durchfuhren kann), der 
aber ebenso erkennen kann, wenn neue Bereichsvorrichtun- 
gen an den Fieldbus-Bus angeschlossen werden, wenn die 
Bereichsvorrichtungen von dem Bus entfernt werden, der 
Daten erkennen kann, die durch die Bereichsvorrichtungen, 
welche an den Bus angeschlossen sind, erzeugt werden, und 
der eine Kopplung mit einer oder mit mehreren Anwender- 
terminals bewirkt, die in dem Host oder irgendeiner anderen 
Vorrichtung gelegen sein konnen, welche in irgendeiner 
Weise an den Host angeschlossen sind. 

Der Fieldbus-Bus unterstiitzt oder erlaubt zweierlei: eine 
rein digitale Kommunikation und er kann auch ein Strom- 
versorgungssighal zu irgendeiner oder zu all den Vorrichtun- 
gen, die an ihn angeschlossen sind, ubertragen, wie bei-' 
spielsweise an die Bereichsvorrichtungen. Alternativ kann 
irgendeine oder konnen alle Fieldbus- Vorrichtungen ihre ei- 
gene Stromversorgung besitzen oder konnen uber separate 
Leitungen mit externen Stromversorgungen verbunden sein. 
Das Fieldbus-Protokoll erlaubt es vielen Vorrichtungen/Ver- 
, drahtungstopologien, inklusive Vielfachvorrichtungen, an 
das gleiche Paar von Drahten oder Leitungen angeschlossen 
zu werden, erlaubt Punkt-zu-Punkt-Verbindungen, in wel- 
chen jede Vorrichtung an einen Kontroller oder einen Host 
uber ein getrenntes Zweidrahtpaar angeschlossen ist (ahn- 
lich den typischen 4-20 raA Analogsystemen) und Baum- 
oder "spur"-Verbindungen realisiert sind, in denen jede Vor- 
richtung mit einem gemeinsamen Punkt in einem Zweilei- 
tungsbus verbunden ist, der beispielsweise aus einem Ka- 
belkasten oder Verzweigungsstuck oder einem AbschluBbe- 
reich in einer der Bereichsvorrichtungen innerhalb eines 
ProzeBsteuer- oder -regelnetzwerks bestehen kann. 

Es konnen Daten uber die Bussegrnente in irgendeiner ei- 
ner Anzahl von unterschiedlichen Kommunikationsbauraten 
oder Geschwindigkeiten gemaB dem Fieldbus-Protokoll ge- 
sendet werden. Beispielsweise schafft das Fieldbus-Proto- 
koll eine 31,25-Kbit/s-Kommunikationsrate (HI) oder eine 
1,0-Mbits- und/oder eine 2,5-Mbit/s-(H2)-Kommunikati- 
onsrate, die in typischer Weise fur eine fortschrittliche Pro- 
zeBsteuerung oder -regelung, Ferneingabe-Aausgabe und fur 
Hochgeschwindigkeits-Fabrikautomatisationsanwendungen 
angewendet werden. In gleicher Weise konnen uber den 
Fieldbus-Bus Daten unter Verwendung einer Spannungs- 
mode-Signalgebung oder einer Strommode-Signalgebung . 
ubertragen werden. Die maximale Lange von irgendeinem 
Fieldbus-Bus oder -Segment ist nicht strikt begrenzt, son- 
dern wird statt dessen durch die Kommunikationsrate, den 
Kabeltyp, die LeitungsgroBe, Busleistungsoptionen usw. 
festgelegt. 

Das Fieldbus-Protokoll klassifiziert die Vorrichtungen, 
die an den Bus angeschlossen werden konnen, in drei pri- 
mare Kategorien, naiiiich die Basis vorrichtungen, die Ver- 
bindungsmastervorrichtungen und die Bruckenvorrichtun- 
gen. Die Basisvorrichtungen konnen kommunizieren, das 
. heiBt Kommunikationssignale auf den Bus senden oder von 
diesem empfangen, sind jedoch nicht dazu befahigt, die Rei- 
henfolge oder Zeitsteuerung der Kommunikation zu steuern, 
die auf dem Bus auftreten. Die Verbindungsmastervorrich- 
tungen bestehen aus Vorrichtungen, die uber dem Bus kom- 
munizieren und die Fahigkeit haben, den FluB und die Zeit- 
steuerung der Kommunikationssignale auf den Bus zu steu- 
ern. Die Briickenvorrichtungen bestehen aus Vorrichtungen, 
die dafur konfiguriert sind, um mit einzelnen Segmenten 
oder Zweigen eines Fieldbus-Busses zu kommunizieren 
oder diese einzelnen Segmente oder Zweige miteinander zu 
verbinden, um ein groBere ProzeBsteuer- oder -regelnetz- 
werk zu erzeugen. Wenn es gewiinscht wird, konnen die 
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Bruckenvorrichtungen zwischen unterschiedlichen Daten- 
geschwindigkeiten und/oder unterschiedlichen Datensigna- 
hsierungsformaten eine Umwandlung vornehmen, die auf 
deh unterschiedlichen Segmenten des Busses verwendet 
werden, konnen Signale verstarken, die zwischen den Seg- 
menten des Busses wandern, konnen die Signale filtern, die 
zwischen unterschiedlichen Segmenten des Busses verlau- 
fen, und konnen lediglich solche Signale durchiassen, die 
dafur bestimmt .sind, durch eine Vorrichtung an einem der 
Bussegmente empfangen zu werden, an welches die Briicke 
gekoppelt ist und/oder konnen andere Aktionen vornehmen, 
die erforderlich sind, um unterschiedliche Segmente des 
Busses zu verbinden. Die Bruckenvorrichtungen, welche die 
Bussegmente verbinden, die mit unterschiedlichen Ge- 
schwihdigkeiten arbeiten, miissen Verbindungsmasterfahig- 
keiten auf der Seite des Segmentes mit niedrigerer Ge- 
schwindigkeit der Briicke besitzen. 

Jede der Fieldbus-Vorrichtungen besitzt die Fahigkeit, 
uber den Bus zu kommunizieren, und, was wichtig ist, die 
Fahigkeit unabhangig eine oder mehrere ProzeBsteuerfunk- 
tiorien durchzufuhren unter Verwendung von Daten, die 
durch die Vorrichtung von dem ProzeB erworben wurden, 
oder von einer unterschiedlichen Vorrichtung erworben 
wurderi, und zwar iiber die Kommunikationssignale auf dem 
Bus. Die Fieldbus-Vorrichtungen besitzen daher die Fahig- 
keit, direkt Abschnitte einer Gesamtsteuer- oder -regelstra- 
tegie zu implementieren, die in der Vergangenheit durch ei- 
nen zentralisierteri digitalen Kontroller durchgefuhrt wur- 
den. Um Steuerfunktionen durchzufuhren, enthalt jede 
Fieldb us- Vorrichtung einen oder mehrere standardisierte 
"Blocke", die in einem Mikroprozessor innerhalb der Vor- 
richtung implementiert sind. Speziell enthalt jede Fieldbus- 
. Vorrichtung einen Ressourcenblock, Null- oder Mehrfunkti- 
onsblocke und Null- oder Mehrwandlerblocke. Diese 
Blocke werden als Blockobjekte bezeichnet. . 

Ein Ressourcenblock speichert und ubertragt spezifische 
Vorrichtungsdaten, die einige Charakteristika einer Field- 
bus- Vorrichtung betreffen, inklusive beispielsweise einem 
Vorrichtungstyp," einer Vorrichtungsrevisionsanzeige und 
Anzeigen daruber, wo andere spezifische Vorrichtungsinfor- 
mationen innerhalb eines Speichers der Vorrichtung erhalten 
werden konnen. Wahrend verschiedene Vorrichtungsher- 
s teller unterschiedliche Typen der Daten in dem Ressour- 
cenblock einer Bereichsvorrichtung speichern konnen, ent- 
halt jede Bereichsvorrichtung, die mit dem Fieldbus-Proto- 
koll konform ist, einen Ressourcenblock, der einige Daten 
speichert. 

Ein Funktionsblock definiert und implementiert eine Ein- 
gabefunktioh, eine Ausgabefunktion oder eine Steuerfunk- 
tion, die der Bereichsvorrichtung zugeordnet ist und es wer- 
den somit Funktionsblocke allgemein als Eingabe-, Aus- 
gabe- und Steuerfunktionsblocke bezeichnet. Es konnen je- 
doch andere Kategorien von Funktionsblocken existieren, 
wie beispielsweise Hybrid-Funktionsblocke, oder konnen 
auch in der Zukunft entwickelt werden. Jeder Eingabe- oder 
Ausgabefunktionsblock erzeugt wenigstens eine ProzeB- 
steuereingangsgroBe (wie beispielsweise eine ProzeBvaria- 
ble aiis einer ProzeBmeBvorrichtung) oder eine ProzeBsteu- 
erausgangsgroBe (wie beispielsweise eine Ventilposition, 
die zu einer Stellvorrichtung gesendet, wird), wahrend jeder 
Steuerfunktionsblock einen Algorithmus verwendet (der in 
seiner Natur geschiitzt oder firmeneigen sein kann), um eine 
oder mehrere ProzeBausgahgsgroBen aus einer oder aus 
mehreren ProzeBeingangsgrbBen und aus Steuereingangs- 
groBen zu erzeugen. Beispiele von Standardfunktionsblok- 
ken umfassen Analogeingangs(Al)-, Analogausgangs(AO)- 
, Vorspann(B)-, Steuerwahl(CS)-, Diskreteingangs(DI)-, 
Diskretausgangs(DO)-, Handlade(ML)-, Proportion al/Dif- 



ferential(PD)-, Proportional/Integral/Difrerential(PDI)-, 
Verhaltnis(RA)- und Signalwahl(SS)-Funktionsbl6cke ! Es 
existieren jedoch andere lypen von Funktionsblocken und 
neue Typen von Funktionsblocken konnen festgelegt oder 
5 hergestellt werden, um in der Fieldbus-Umgebung zu arbei- 
ten. 

Ein Wandlerblock koppelt die EingangsgroBen und Aus- 
gangsgroBen eines Funktionsblockes an die ortlichen Hard- 
warevorrichtungen, wie beispielsweise an Sensoren und 

10 Vorrichtungsstellglieder, um die Funktionsblocke dazu zu 
befahigen, die AusgangsgroBen von ortlichen Sensoren zu 
lesen und die ortlichen Vorrichtungen mit Befehlen zu ver- 
sehen, um eine oder mehrere Funktionen, wie beispiels- 
weise das Bewegen eines Ventilteiles auszufiihren. Wandler- 

15 blocke enthalten in typischer Weise Inforrnationen, die er- 
forderlich sind, um Signale zu interpretieren, die durch eine 
brtliche Vorrichtung abgeleitet wurden, und um in richtiger 
Weise die ortlichen Hardwarevorrichtungen zu steuern, wo- 
bei diese Inforrnationen beispielsweise Information enthal- 

20 ten, die den Typ einer orthchen Vorrichtung identifizieren, 
Eichungsinformationen, die einer ortlichen Vorrichtung zu- 
geordnet sind, betreffen usw. Ein einzelner Wandlerblock ist 
in typischer Weise jedem Eingabe- oder Ausgabefunktions- 
block zugeordnet. 

25 Die meisten Funktionsblocke sind dazu befahigt, Alarm 
oder Ereignisanzeigen zu generieren, basierend auf vorbe- 
stimrnten Kriterien, und haben'die Fahigkeit unterschiedlich 
in verschiedenen Modi zu arbeiten. Allgemein gesagt, kon- 
nen Funktionsblocke in einem automatischen Modus arbei- 

30 ten, in welchem beispielsweise der Algorithmus eines Funk- 
tionsblockes automatisch arbeitet; in einem Operatormodus 
arbeiten, in welchem der Eingang oder der Ausgang eines 
Funktionsblockes von Hand gesteuert wird; einem AuBer- 
Servicemodus arbeiten, in welche der Block nicht arbeitet; 

35 in einem Kaskadenmodus arbeiten, in welchem die Opera- 
tion des Blockes von der AusgabegroBe eines verschiedenen 
Blockes beeinfluBt wird (durch diesen bestirnmt wird); und 
in einem oder mehreren Entfernungsmodi arbeiten, in wel- 
chen ein entfernt gelegener Computer den > Modus des 

40 Blocks bestimmt. Es existieren jedoch in dem Fieldbus-Pro- 
tokoll andere Betriebsmodi. 

Als wichtiges Merkmal besitzt jeder Block die Fahigkeit, 
mit anderen Blockeri in der gleichen oder unterschiedlicHen 
Bereichsvorrichtungen uber den Fieldbus-Bus zu kommuni- 

45 zieren, und zwar uhter Verwendung von Standardnachrich- 
tenformaten, die durch das Fieldbus-Protokoll festgelegt 
sind. Als ein Ergebnis konnen Kombinationen von Funk- 
tionsblocken (in den gleichen oder unterschiedlichen Vor- 
richtungen) miteinander kommunizieren, um eine oder meh- 

50 rere dezentralisierte Regelschleifen zu erzeugen. Es kann 
somit beispielsweise ein PID-Funktionsblock in einer Be- 
reichsvorrichtung iiber den Fieldbus-Bus angeschlossen 
. sein, um eine AusgangsgroBe eines AI-Funktionsblocks in 
einer zweiten Bereichsvorrichtung zu empfangen, um Daten 

55 an einen AO-Funktionsblock in einer dritten Bereichsvor- 
richtung zu lief em, um eine. AusgangsgroBe eines AO- 
Funktionsblocks als RiickkopplungsgroBe zu empfangen, 
um eine ProzeBregelschieife getrennt und neben irgendei- 
nem zentralisierten Kontroller zu erzeugen. Auf diese Weise 

60 bewegen Kombinationen vori Funktionsblocken die Steuer- 
funktionen aus einer zentralisierten DCS-Umgebung heraus, 
was die Moglichkeit schafft, daB DCS-Vielfunktionskon- 
troller Uberwachungs- oder Koordinationsfunktionen 
durchfuhren. Ferner erlauben es die Funktionsblocke, eine 

65 graphische blockorientierte Struktur zu verwenden, und 
zwar eine einfache Konfiguration eines Prozesses, und er- 
moglicheri die Verteilung der Funktionen unter den Be- 
reichsvorrichtungen von unterschiedlichen Zulieferern, da 
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diese Blocke ein konsistentes Kommunikationsprotokoll 
verwenden. 

Zusatzlich zu dem Merkmal, daB Bereichsvorrichtungen 
Blockobjekte enthalten und implementieren, enthalt jede 
Bereichsvorrichtung ein oder mehrere andere Objekte, in- 
klusive Verbindungsobjekten, Trendobjekten, Wamobjekten 
und Betrachtungsobjekten. Verbindungsobjekte definieren 
die Verbindungen zwischen den Eingangen und Ausgangen 
der Blocke (wie den Funktionsblocken), .und zwar sowohl 
intern in der Bereichsvorrichtung als auch uber den Field- 
bus-Bus hinweg. Trendobjekte erlauben einen ortlichen 
Trend von Funktionsblockparametern fiir den Zugriff auf 
andere Vorrichtungen, wie beispielsweise einen Host oder 
einen Kontroller. Trendobjekte halten historische Kurzzeit- 
daten, die einige, beispielsweise den Funktionsblockpara- 
meter, betreffen und berichten diese Daten an andere Vor- 
richtungen oder Funktionsblocke, und zwar tiber den Field- 
bus-Bus in einer asynchronen Weise. Wamobjekte berichten 
uber Alarme und Ereignisse iiber den Fieldbus-Bus. Diese 
Alarme oder Ereignisse konnen irgendein Ereignis betref- 
fen, welches innerhalb einer Vorrichtung stattfindet oder in- 
nerhalb einem der Blocke einer Vorrichtung. Betrachtungs- 
objekte sind vordefinierte Gruppierungen von Blockpara- 
metern, die in standardisierten Mensch/Maschine-Schnitt- 
stellenbereichen verwendet werden und die zu anderen Vor- 
richtungen gesendet werden konnen, und zwar unter Ver- 
wendung von asynchronen Ubertragungen, um eine Be- 
trachtung von Zeit zu Zeit zu ermoglichen. 

In Fig. 2 sind drei Fieldbus-Vorrichtungen veranschau- 
. licht, die beispielsweise aus irgendeiner der Bereichsvor- 
richtungen 43-50 von Fig. 1 bestehen, und diese enthalten 
Ressourcenblocke 58, Funktionsblocke 60, 61 oder 62 und . 
Wandlerblocke 63 und 64. In der ersten Vorrichtung ist der 
Funktionsblock 60 (der aus einem Eingabefunktionsblock 
besteht) iiber den Wandlerblock 63 mit einem Sensor 65 ge- 
koppelt, der beispielsweise aus einem Temperatursensor, ei- 
nem Sollpunktanzeigesensor usw. bestehen kann. In der 
zweiten Vorrichtung ist der Funktionsblock 61 (der aus ei- 
nem Ausgabefunktionsblock bestehen kann) iiber den 
Wandlerblock 64 an eine Ausgabevorrichtung, wie bei- 
spielsweise ein Ventil 66, gekoppelt. In der dritten Vorrich- 
tung enthalt der Funktionsblock 62 (der aus einem Steuer- 
funktionsblock bestehen -kann) ein Trendobjekt 67, welches 
diesem zugeordnet ist, um den Trend des Eingangsparame- 
ters des Funktionsb locks 62 zu ermitteln. 
' Die Verbindungsobjekte 68 definieren die Verbindungen 
von Blockparametern von jedem der zugeordneten Blocke 
und die Wamobjekte 69 erzeugen Alarme oder Ereignisbe- 
nachrichtigungen fur jeden der zugeordneten Blocke. Be- 
trachtungsobjekte 70 sind mit jedem der Funktionsblocke 
60, 61 und 62 zugeordnet und enthalten Gruppendatenlisten 
fur die Funktionsblocke, zu denen sie zugeordnet sind. 
Diese Listen enthalten Informationen, die fur jeden eines 
Satzes von unterschiedlich definierten Betrachtungen erfor- 
derlich sind. Naturlich stellen die Vorrichtungen von Fig. 2 
lediglich Beispiele dar und andere Zahlen und Typen von 
Blockobjekten, Verbindungsobjekten, Wamobjekten, 
Trendobjekten und Betrachtungsobjekten konnen in irgend- 
einer Bereichsvorrichtung vorgesehen sein. 

Um eine Kornmunikation und Steueraktivitaten zu imple- 
mentieren und auszufuhren, verwendet das Fieldbus-Proto- 
koll drei allgemeine Kategorien der Technologie, die als 
eine physikaHsche Schicht, als ein Kornmunikations-"S ta- 
per und eine Anwenderschicht definiert sind. Die Anwen- 
derschicht enthalt die Steuer- und Konfigurationsfunktio- 
nen, die in Form der Blocke vorgesehen werden (wie bei- 
spielsweise den Funktionsblocken) und Objekte innerhalb 
irgendeiner bestimmten ProzeBsteuervorrichtung oder Be- 



reichsvorrichtung. Die Anwenderschicht ist in typischer 
Weise in einer geschutzten Weise ausgelegt oder konstruiert, 
und zwar durch den Hers teller der Vorrichtung, muB jedoch 
die Fahigkeit haben, Nachrichten zu empfangen und auszu- 

5 senden, und zwar in Einklang mit dem Standardnachrichten- 
format, welches durch das Fieldbus-Protokoll festgelegt ist, 
und muB durch einen Anwender in der standardisierten 
Weise konfigurierbar sein. Die physikalisehe Schicht und 
der Kommunikationsstapel sind erforderhch, um eine Nach- 

10 richtenverbindung zwischen unterschiedlichen Blocken un- 
terschiedlicher Feld- oder Bereichsvorrichtungen in einer 
standardisierten Weise zu bewirken, und zwar unter Ver- 
wendung eines Zweidrahtbusses, und konnen durch das gut 
bekannte Open-Systems-Interconnect-(OSI)-Schicht-Kom- 

15 munikationsmodell modelliert sein. 

Die physikalisehe Schicht, die der OSI-Schicht 1 ent- 
spricht, ist in jeder Bereichsvorrichtung und in dem Bus ein- 
gebettet und arbeitet dahingehend, um elektromagnetische 
Signale, die von dem Fieldbus-Ubertragungsmedium (dem 

20 Fieldbus-Zweidrahtbus) empfangen werden, in Nachrichten 
umzusetzen, die durch den Kommunikationsstapel der Be- 
reichsvorrichtung verwendet werden konnen. Die physikali- 
sehe Schicht kann als ein Fieldbus-Bus und elektromagneti- 
schen Signalen, die auf dem Bus an den Eingangen und Aus- 

25 gangen der Bereichsvorrichtungen vorhanden sind, betrach- 
tet werden. 

Der Kommunikationsstapel, der in jeder Fieldbus- Vor- 
richtung vorhanden ist, enthalt eine Datenverbindungs- 
schicht, die der OSI-Schicht 2 entspricht, eine Fieldbus-Zu- 

30 griffs-Sub-Schicht und eine Fieldbus-Nachricht-Spezifikati- 
onsschicht Die Anwenderschicht des Fieldbus-Protokolls 
besteht aus einer Schicht, die in dem OSI-Protokoll nicht de- 
finiert ist. Jede Schicht in dem Kommunikationsstapel ist fur 
die Kodierung und Dekodierung eines Abschnitts der Nach- 

35 richt oder des Signals verantwortlich, welches iiber den 
Fieldbus-Bus ubertragen, wird. Als ein Ergebnis addiert oder 
entfernt jede Schicht des Kommunikationsstapels gewisse 
Abschnitte des Fieldbus-Signals, wie beispielsweise die 
Praambeln, Startbegrenzer und Endebegrenzer, und in eini- 

40 gen Fallen, dekodiert sie Bandabschnitte des Fieldbus-Si- 
gnals, um eine Idehtifizierung dariiber durchzufuhren, ob 
der Rest des Signals oder der Nachricht gesendet werden 
sollte oder ob das Signal geloscht werden sollte, da es bei- 
spielsweise eine Nachricht oder Daten fur Funktionsblocke 

45 enthalt, die nicht innerhalb der empfangenden Bereichsvor- 
richtung vorhanden sind. 
' Die Datenverbindungsschicht steuert die Ubertragung 
von Nachrichten auf dem Fieldbus-Bus und managt den Zu- 
griff auf den Bus gemaB einer deterministischen.zentrali- 

50 sierten Busablaufsteuerung (scheduler), der als ein yerbin- 
dungsaktiver Abwickler bezeichnet wird, der im folgenden 
noch mehr in Einzelheiten beschrieben wird. Die Datenver- 
bindungsschicht entfemt eine Praambel von den Signalen 
auf dem Ubertragungsmedium und kann die empfangene 

55 Praambel verwenden, um den internen Takt der Bereichs- 
vorrichtung mit dem ankommenden Fieldbus-Signal zu syn- 
chronisieren. In ahnlicher Weise wandelt die Datenverbin- 
dungsschicht die Nachrichten auf dem Kommunikationssta- 
pel in physikalisehe Fieldbus-Signale um und kodiert diese 

60 Signale mit der Taktinformatipn, um ein "synchrones seriel- 
les" Signal mit einer richtigen Praambel fur die Ubertragung 
auf dem Zweidrahtbus oder -schleife zu erzeugen. Wahrend 
des Dekodierungsprozesses erkennt die Datenverbindungs- 
schicht spezifische Kodes innerhalb der Praambel, wie bei- 

65 spielsweise Startbegrenzer und Endebegrenzer, um den An- 
fang und das Ende einer bestimmten Fieldbus-Nachricht zu 
identifizieren, und kann eine Priifsumme erstellen, um die 
Integritat des Signals oder der Nachricht, die von dem Bus 
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empfarigen wurde, zii verifizieren. In ahnlicher Weise uber- 
tfagt.die Datenverbindungsschicht die Fieldbus-Signale auf 
den Bus, indem sie Start- und Endebegrenzer zu den Nach- 
richten auf dem Datenkommunikationsstapel hinzufugt und 
indem sie diese Sighale auf das Ubertragungsmedium zu ei- 
ner geeigneten Zeit setzt; 

Die Fieldbus-Nachrichten-Spezifikationsschicht erlaubt 
es der Anwenderschicht (das heiBt den Funktionsblocken, 
Objekten usw. einer Bereichsvorrichtung), iiber den Bus zu 
komrnunizieren, und zwar unter Verwendung eines Stan- 
dards atzes von Nachrichtenformaten und beschreibt den 
Kommunikationsservice, die Nachrichtenfprmate und die 
Protokollverhaltensweisen, die erforderlich sind, um Nach- 
richten herzustellen, die auf den Kommunikationsstapel zu 
setzen sind und die fur die Anwenderschicht vorzusehen 
sirid. Da die Fieldbus-Nachrichteh-Spezifikationsschicht 
standardisierte Komrnunikationen fur die Anwenderschicht 
liefert, sind spezifische Fieldbus-Nachrichten-Spezifikati- 
ons-Kommunikationsdienste fur jeden Typ des oben be- 
schriebenen Objekts festgelegt. Bei spiels weise enthalt die 
Fieldbus-Nachrichten-Spezifikationsschicht Objektwdrtef- 
buchdienste, die es dem Anwender ermoglichen, in einem 
Objektworterbuch einer Vorrichtung zu lesen. Das Objekt- 
worterbuch speichert Objektbeschreibungen, welche jedes 
der Objekte beschreiben oder identifizieren (wie beispiels- 
weise Blockobjekte), und zwar von einer Vorrichtung. Die 
Fieldbus-Nachrichten-Spezifikationsschicht ermoglicht 
auch variable Zugriffsdienste, die es einem Anwender er- 
moglichen, Kommunikationsbeziehungen, die als virtuelle 
Kqmmunikationsbeziehungen (VCRs) bekannt sind und im 
folgenden beschrieben werden, die einer oder mehreren Ob- 
jekten einer Vorrichtung zugeordnet sind, zu lesen und zu 
andern. Dariiber hinaus schafft die Fieldbus-Nachrichten- 
Spezifikationsschicht ein Kontextmanagement,' variable Zu- 
griffsdienste, Ereignisdienste, Hochlade- und Herunterlade- 
dienste und Programmaufrufdienste, die alle in Verbindung 
mit dem Fieldbus-Protokoll gut bekannt sind und daher hier 
nicht in Einzelheiten beschrieben werden. Die Fieldbus-Zu- 
gfiffs-Sub-Schicht bildet die Fieldbus-Nachrichten-Spezifi- 
kationsschicht in der Datenverbindungsschicht ab. 

Um einen Betrieb dieser Schichten zuzulassen oder zu er- 
moglichen, enthalt jede Fieldbus- Vorrichtung eine Manage- 
mentinformationsbasis (MIB), die aus einer Datenbasis oder 
Datenbankbesteht, die VCRs, dynamische Variable, statisti- 
"sche GroBen, Zeitsteuerplane, Funktionsblockausfiihrungs- 
zeitsteuerplane und eine Vorrichtungsetikette (device tag) 
und Adresseninformationen speichert. Natiirlich konnen die 
Informationen innerhalb der MIB zugegriffen werden oder 
zu irgendeiner Zeit unter Verwendung der Standard- Field- 
bus-Nachrichten oder -Befehle geandert werden. Ferner ist 
gewohnlich eine Vorrichtiingsbeschreibung fiir jede Vor- 
richtung vorgesehen, um einem Anwender oder einem Host 
einen weiten Uberblick an Informationen in der VFD zu ge- 
ben. Eine Vorrichtungsbeschreibung, die in typischer Weise 
in Form einer Sendeerlaubnis, um von einem Host verwen- 
det zu werden, festgelegt ist, speichert Informationen, die 
fiir den Host erforderlich sind, um die Bedeutung der Daten 
in den VFDs einer Vorrichtung zii verstehen. 

Wie ersehen werden kann, muB die Implementierung von 
irgendeiner Steuerstrategie unter Verwendung der Funk- 
tionsblocke, die iiber ein ProzeBregelnetzwerk verteilt ange- 
ordnet sind, die Ausfuhrung der Funktionsblocke prazise 
geplant werden, und zwar in bezug auf die Ausfuhrung von 
anderen Funktionsblocken in einer bestimmten Regel- 
schleife. In ahnlicher Weise muB die Kommunikation zwi- 
schen"unterschiedlichen Funktionsblocken in praziser Weise 
auf dem Bus geplant werden, so' daB die richtigen Daten zu 
jederri Funktionsbiock ubertragen werden, bevor dieser 



Block ein Programm ausfuhrt. 

Der Weg, mit welchem unterschiedliche Bereichsvorrich- 
tungen (und unterschiedliche Blocke innerhalb den Be- 
reichsvorrichtungen) iiber das Fieldbus-Obertragungsme- 

5 dium komrnunizieren, soil nun beschrieben werden. Damit 
eine Kommunikation stattfindet, arbeitet eine der Verbin- 
dungsmastervorrichtungen auf jedem Segment der Field- 
bus-Schleife als ein verbindungsaktiver Abwickler (LAS), 
der aktiv die Kommunikation auf dem zugeordneten Seg- 

10 ment des Busses abwickelt und steuert. Das LAS fur jedes 
Segment des Busses speichert einen Kbmmunikationsplan 
(einen verbindungsaktiven Plan), der Zeitpunkte enthalt, bei 
denen jeder Funktionsbiock von jeder Vorrichtung geplant 
ist, periodisch die Kommunikationsaktivitat auf dem Bus zu 

15 starten und auch die Lange der Zeit geplant ist, wahrend 
welcher diese Kommunikationsaktivitat stattfinden muB. 
Wahrend lediglich eine und nur eine aktive LAS- Vorrich- 
tung auf jedem Segment des Busses vorhanden sein kann, 
konnen andere Verbindungsmastervorrichtungen als Bak- 

20 kup-LASs dienen und konnen beispiels weise dann aktiv 
werden,. wenn die momentane LAS ausfallt. Die Basis vor- 
richtungen haben nicht die Fahigkeit, eine LAS zu irgendei- 
nem 2^eitpunkt zu werden. 

ALLgemein gesagt, werden die Kornmunikationsaktivita- 

25 ten iiber den Bus eingeteilt in Wiederholungsmakrozyklen, 
die den synchronen Kommunikationsplan fur den Bus defi- 
nieren. Eine Vorrichtung kann aktiv sein, das heiBt Daten zu 
irgendeinem Segment des Busses senden oder von diesem 
empfangen, und zwar selbst wenn sie physikalisch an ein 

30 unterschiedliches Segment des Busses angeschlossen ist, 
und zwar durch eine koordinierte Operation der Briicken 
und der LASs auf dem Bus. 

Wahrend jedes Makrozyklusses fuhrt jeder der Funk- 
tionsblocke, die auf einem bestimmten Segment des Busses 

35 aktiv sind, gewohnlich zu einem unterschiedlichen, jedoch 
prazise geplanten (synchronen) Zeitpunkt oder Zeit ein Pro- 
gramm durch. Wenn der Funktionsbiock einen Ausgangspa- 
rameter hat, der mit einem anderen Parameter extern zu der 
Vorrichtung verkettet ist, so veroffentlicht der Funktions- 

40 block seine Ausgangsdaten in einer prazise geplanten Zeit 
im Ansprechen auf einen Erzwingungsdatenbefehl, der 
durch die LAS erzeugt wurde. In bevorzugter Weise ist jeder 
Funktionsbiock so eingeplant, daB er seine Ausgabedaten 
kurz nach dem Ende der Ausfuhrungsperiode des Funk- 

45 . tionsblockes veroffentlicht. Ferner sind die Daten veroffent- 
lichungszeitpunkte der verschiedenen Funktionsblocke in 
serieller Form geplant oder einer Ablaufsteuerung unterwor- 
fen, so daB keine zwei Funktionsblocke auf einem bestimm- 
ten Segment des Busses Daten zur gleichen Zeit verdffentli- 

50 chen. Wahrend der Zeit, wahrend welcher eine synchrone 
Kommunikation nicht stattfindet, hat jede Bereichsvorrich- 
tung die Moglichkeit, ihrerseits Alarmdaten, Betrachtungs- 
daten usw. in einer asyrichronen Weise zu senden, und zwar 
unter Verwendung von sendeanfrage-angetriebenen Kom- 

55 munikationen. Der Ausfuhrungs- oder Ablaufplan ist in ei- 
ner Mangementinformationsbasis (MEB) abgespeichert, es 
sind die Ausfuhrungszeitpunkte der Blocke in den Funk- 
tionsblocken gespeichert und es sind die Zeitpunkte zum 
Senden der Zwangsdatenbefehle zu jeder der Vorrichtungen 

60 auf einem Segment des Busses in der MEB der LAS- Vorrich- 
tung fur. dieses Segment gespeichert. Diese Zeitpunkte wer- 
den in typischer Weise als Offsetzeiten gespeichert, da sie 
die Zeiten oder Zeitpunkte identifizieren, zu welchen Funk- 
tionsbiock • ein Programm ausfuhren oder Daten senden 

65 muB, und zwar in einer Versetzung (Offset) vom Anf ang ei- 
ner "absoluten Verbindungsplanstartzeit", die alien Vorrich- 
tungen, die an den Bus angeschlossen sind, bekannt ist. 
Um Komrnunikationen zwischen jedem Makrozyklus zu 
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bewirken, sendet die LAS einen Zwangsdatenbefehl zu je- 
der der Vorrichtungen auf dem zugeordneten Bussegment 
gemaB der Liste der Sendezeitpunkte, die in dem verbuv- 
dungsaktiven Plan gespeichert sind. Nach dem Empfang ei- 
nes Zwangsdatenbefehls veroffentlicht ein Funktionsblock 5 
einer Vorrichtung seine Ausgabedaten auf dem Bus. Da je- 
der der Funktionsblocke typischerweise einer Ablaufsteue- 
rung unterliegt, um ein Programm aus zufuhren, so daB die 
Ausfuhrung des Programms dieses Blocks vervollstandigt 
wird, kurz bevor der Block im Plan dafur vorgesehen ist, ei- 10 
nen Zwangsdatenbefehl zu empfangen, sollten die Daten, 
die im Ansprechen auf einen Zwangsdatenbefehl veroffent- 
licht werden, die allerletzten Ausgangsdaten des Funktions- 
blockes sein. Wenn jedoch ein Funktionsblock in der Pro- 
grammausfuhrung langsam ist und keine neuen Ausgangs- 15 
groBen verriegelt hat, wenn er den Zwangsdatenbefehl emp- 
fangt, veroffentlicht der Funktionsblock die Ausgangsdaten, 
die wahrend. des letzten Laufes des Funktionsblockes er- 
zeugtwurden. 

Wahrend der Perioden, in welchen die Zwangsdatenver- 20 
offentlichungen nicht geplant sind, kann die LAS asyn- 
chrone Kommunikationsaktivitaten aktivieren. Um eine 
asynchrone Kommunikation zu bewirken, sendet die LAS 
eine DurchlaB-Token-Nachricht zu einer bestimmten Be- 
reichs vorrichtung. . Wenn eine Bereichs vorrichtung eine 25 
DurchlaB-Token-Nachricht empfangt, erlangt diese Be- 
reichsvorrichtung vollen Zugriff auf den Bus. (oder ein Seg- 
ment desselben) und kann asynchron Nachrichten senden, 
wie .beispielsweise Aiaminachrichten, Trenddaten, Opera- 
tbr-Sollpunktanderungen usw., bis die Nachrichten vervoll- 30 
standigt sind oder bis eine maximal zugewiesene "Token- 
Haltezeit" verstrichen ist. Danach gibt die Feldvorrichtung 
den Bus frei (oder .'irgendein bestimmtes Segment dessel- 
. ben) und die LAS sendet eine DurchlaB-Token r NaChricht zu 
einer anderen Vorrichtung. Dieser ProzeB wird wiederholt, 35 
bis die LAS entweder gernaB dem Plan einen Zwangsdaten- 
befehl aussendet, um eine synchrone Kommunikation zu be- 
wirken, oder die LAS eine Netzwerkwartung durchzufuhren 
hat. Natiirlich kann abhangig vom AusmaB des Nachrich- 
teriverkehrs und der Zahl der Vorrichtung und der Blocke, 40 
die an ein bestimmtes Segment des Busses gekoppelt sind, 
, nicht jede Vorrichtung eine DurchlaB-Token-Nachricht wah- 
rend jedes Makrozyklusses empfangen. 

Fig. 3 veranschaulicht ein Zeitsteuerschema, welches die 
Zeitpunkte herausgreift, bei den die Funktionsblocke (mit 45 
ALloopi, PIDLOOPb AI L0 0P2> AOlqopi, SS L oop2 und PID- 
LOOP3) ein Programm ausfuhren, und. zwar wahrend jedes 
Makrozyklusses eines Bussegmentes, und die Zeitpunkte, 
bei denen eine synchrone Kommunikation wahrend jedes 
Makrozyklusses stattfindet, der dem' Bussegment zugeord- 50 
net ist; In dem Zeitsteuerplan von Fig. 3 ist die Zeit auf der 
■ horizontalen Achse aufgetragen und die Aktivitaten, die den 
unterschiedlichen Funktionsblocken zugeordnet sind, sind 
auf der vertikalen Achse veran schaulicht. Die Regelschleife 

• (diezumZweckederErlauterungwillkurlichist),in welcher 55 
jeder der Funktionsblocke arbeitet, ist in Fig. 3 als Iridexan- 
gabe identifiziert. Somit verweist AI LO opi auf den AI-Funk- 
tionsblock von beispielsweise einern Sender, der innerhalb 

\, einer ersten Regelschleife arbeitet, PID LO opi verweist auf 
v den PH)-Funktionsblock in beispielsweise einem Stellwerk/ 60 

• Ventii; welches innerhalb der ersten Regelschleife arbeitet, 

.- usw. Die Blockausfuhrungsperiode von jedem der veran- 
;scnaulichten Funktionsblocke ist durch ein kreuzstrichher- 

1 '^tes/Kastchen herausgestellt, wahrend jede geplante syn- 

• .'chrone Kommunikation durch einen vertikalen Balken in 65 
. Fig. 3 identifiziert ist. . 

Somit .fuhrt gemaB dem Zeitsteuerplan von Fig. 3 wah- 
Tend irgencieines bestimmten Makrozyklusses des Busseg- 



ments der AI L ooPi- Funktionsblock: zu ^rst ein Programm 
aus, und zwar fur die Zeitperiode, die durch das Kastchen 71 
spezifiziert ist. Dann, wahrend der Zeitperiode, die durch 
den vertikalen Balken 72 angezeigt ist, wird die Ausgangs- 
groBe des AI LO opi-F unkt i onsblockes auf dem Bussegment 
im Ansprechen auf einen Zwangsdatenbefehl von der LAS 
fur das Bussegment veroffentlicht. In ahnlicher Weise zei- 
gen die Kastchen 74, 76, 78, 80 und 80 die Ausfuhrungszei- 
ten der jeweiligen Funktionsblocke PIDloopi> AIloop2> AO- 
loopi, SS L oop2 und PID L0O P3, die fur jeden der unterschied- 
lichen Blocke verschieden sind, an, wahrend die vertikalen 
Balken 82, 84, 86, 88 und 89 die Zeiten anzeigen, zu wel- . 
chen die jeweiligen Funktionsblocke PrD LO oPb AILOOP2, 
AOloopi, SS LOO P2 und PID L ooP3 Daten auf dem Busseg- 
ment veroffentlichen. 

Wie zu erkennen ist, veranschaulicht das Zeitsteuer- 
schema von Fig. 3 auch die Zeitpunkte oder Zeiten, die fur 
asynchrone KommunikaUonsaktivitaten verfugbar sind, die 
wahrend der Ausfuhrungszeiten von irgendeinem der Funk- 
tionsblocke auftreten konnen und wahrend der Zeit am Ende 
des Makrozyklusses, wahrend welcher keiner der Funk- 
tionsblocke ein Programm ausfuhrt und wenn keine syn- 
chrone Kommunikation auf dem Bussegment stattfindet. 
Wenn es natiirlich gewunscht wird, konnen unterschiedliche 
Funktionsblocke beabsichtigt so eingeplant werden,^daB sie 
ein Programm zur gleichen Zeit ausfuhren und daB nicht alle 
Funktionsbldcke Daten auf dem Bus verorTentlichen mus- 
sen, wenn beispielsweise keine andere Vorrichtung an den 
Datenteil hat, die durch einen Funktionsblock erzeugt wer- 
den. 

Bereichsvorrichtungen konnen Daten veroffentlichen 
oder ubertragen und konnen Nachrichten uber den Fieldbus- 
Bus ubertragen, und zwar unter Verwendung von einer der 
drei virtuellen Kommunikationsbeziehungen (VCRs), die in. 
der Fieldbus-Zugriffs-Sub-Schicht des Stapels von jeder Be- 
reichsvorrichtung definiert sind. Ein Client/Server- VCR 
wird fur in eine Warteschlange eingereihte, nicht geplante, 
vom Anwender initialisierte Eins-zu-Eins-Kommunikatio- 
nen zwischen den Vorrichtungen auf dem Bus verwendet. 
Solche in eine Warteschlange eingereihten Nachrichten wer- 
den in der Reihenfolge gesendet und empfangen, wie sie fur 
die Aussendung geliefert werden, und zwar gemaB deren 
Prioritat, ohne daB dabei fruhere Nachrichten tiberschrieben 
werden. Somit kann eine Bereichsvorrichtung einen Client/ 
Server- VCR verwenden, wenn sie eine DurchlaB-Token- 
Nachricht von einem LAS empfangt, um eine Anfragenach- 
richt zu einer anderen Vorrichtung auf dem Fieldbus-Bus zu 
senden. Der Anfrager wird als "Client" bezeichnet und die 
Vorrichtung, die die Anfrage empfangt, wird als "Server" 
bezeichnet. Der Server sendet eine Antwort, wenn er eine 
Durchgangs-Token-Nachricht von dem LAS empfangt. Der 
Client/Server- VCR wird beispielsweise 'dazu verwendet, um. 
operator-initialisierte Anfragen, wie beispielsweise Soll- 
punktanderungen, Abstimmparameter, Zugriff und Ande- 
rungen, Alarmbestatigungen und Vorrichtungs-up und - 
downloads zu bewirken. 

Ein Reportverteiler VCR wird fur die in eine - Warte- 
schlange eingereiht, nicht geplanten, anwenderinitialisierten 
Kommunikationen von einer bis mehreren Kommunikatio- 
nen verwendet. Wenn beispielsweise eine Bereichsvorrich- 
tung mit einem Ereignis- oder einem Trendreport ein Durch- 
gangs-Token von einer LAS empfangt, so sendet diese Be- 
reichsvorrichtung ihre Nachricht zu einer "Gruppen- 
adresse", die in der Fieldbus-Zugriffs-Sub-Schicht des 
Kommunikationsstapels dieser Vorrichtung definiert ist. Die 
Vorrichtungen,. die dafur konfiguriert sind, um auf dieses 
VCR zu horchen, werden den Report empfangen. Der Re- 
portverteilungs-VCR-Typ wird in typischer Weise durch die 



DE 199 40 230 A 1 



19 



20 



Fieldbus- Vorrichtungen verwendet, urn Alarmbenachrichti- 
gungeri zu Bedienungskonsolen zu senden. 

Ein Herausgeber/Benutzer-VCR-iyp wird dazu verwen- 
det, um eine bis viele Kommunikationen zu puffern. Die ge- 
pufferten Kommunikationen sind solche, die lediglich die 
spateste Version der Daten speichem und senden und es 
iiberschreiben daher neue Daten vollstandig die friiheren 
Daten. Die FunktionsausgangsgroBen umfassen beispiels- 
weise gepufferte Daten. Eine n Ver6ffentlicher"-Bereichs- 
vorrichtung veroffentlicht oder sendet eine Nachricht unter 
Verwendung des Veroffentlicher/Benutzer-VCR-iyps an 
alle die ,, Benutzer"-Bereichs-vorrichtungen an den Field- 
bus-Bus, wenn die Veroffentlichervorrichtung eine Zwangs- 
datennachricht von der LAS oder von einer Benutzer- oder 
Teilnehmervorrichtung ernpfangt. Die Ver6ffentlicher-/Be- 
nutzerbeziehungen sind vorbestimmt und sind innerhalb der 
Fieldbus-Zugriffs-Sub-Schicht des Kommunikationsstapels 
von jeder Bereicbsvorrichtung definiert und gespeichert. 

Um richtige Kommunikationsaktivitaten iiber den Field- 
bus-Bus sicherzustellen, sendet jede LAS periodisch eine 
Zeitverteilungsnachricht an alle Bereichsvorrichtungen, die 
an ein Segment des Busses angeschlossen sind, was des den 
empfangenden Vorrichtungen ermoglicht, ihre ortliche Da- 
tenverbindungszeit so einzustellen, daB sie miteinander syn- 
chronisiert sind. Zwischen diesen Synchronisationsnach- 
richten wird die Taktzeit unabhangig in jeder Vorrichtung 
beibehalten, und zwar basierend auf deren eigenem inter- 
nem Takt. Eine Taktsynchronisation erlaubt es den Be- 
reichsvorrichtungen, die Funktionsblock-Programmausfiih- 
rung mit dem Netzwerk zu synchronisieren. 

Wie aus der oben gegebenen Erlauterung des Fieldbus- 
Kommunikationsprotokolls hervorgeht, erfordert eine Kom- 
munikation mit irgendeiner speziellen Vorrichtung oder ei- 
nem Funktionsblock, der innerhalb des Fieldbus-Abschnitts 
des ProzeBregelnetzwerks 10 gelegen ist, das heiBt an den 
Bus 42 angeschlossen ist, detailliertes Wissen daruber, auf 
welche Weise die Kommunikation innerhalb des Fieldbus- 
Protokolls im allgemeirien bewirkt wird, als auch eine Be- 
trachtung daruber und ein Wissen davon, wie der Fieldbus- 
Bus'42 speziell aufgebaut ist und wann Kommunikationen, 
die diesem zugeordnet sind, geplant sind und erlaubt wer- 
den. Dies macht es seinerseits fur den Designer der ProzeB- 
regelroutine schwierig, die in dem Kontroller 12 implemen- 
tiert ist, Kommunikationen mit den Vorrichtungen innerhalb 
des Fieldbus-Abschnitts des ProzeBregelnetzwerks zu im- 
plementieren und zu planen, das heiBt den Vorrichtungen, 
die an den Bus 42 angeschlossen sind. Da daruber hinaus 
Standard- oder regulare Kommunikationen zwischen, den 
Funktionsblocken in einer synchronen Weise iiber den Bus 
42 erfolgen, muB der Kontroller 12 so konfiguriert sein, um 
all diese. Kommunikationen oder Nachrichten oder wenig- 
stens die einen zu empfangen, die er zur Ausfuhrung der 
Steuer- oder Regelroutihe benotigt. Es kann eine entmuti- 
gende Aufgabe auf Seiten des Kontrollers 12 werden, den 
Empfang und die Speicherung von all den Informationen zu 
koordinieren, die auf dem Bus 42 flieBen, und zwar in einer 
Weise, die effizient durch den Kontroller 12 verwendet wer- 
den kann, um die Steuerung des gesamten Prozesses 19 zu 
bewirken. Um ferner Informationen zu empfangen, die nicht 
syrichron iiber den Bus 42 gesehdet werden, muB der Kon- 
troller 12 eine Anfrage nach dieser Information aus senden, 
die, wie oben erlautert wurde, asynchron iiber den Bus 42 
gesendet wird. Da es fur den Kontroller 12 keineri Weg gibt, 
zu bestimmen oder zu bewirken, wann die asynchrone An- 
frage an die geeignete Vorrichtung iibergeben wird (da die 
Zeitsteuerung diese Anfrage direkt durch die anderen asyn- 
chronen Kommunikationen beeinfluBt wird, die auf dem 
Bus 42 stattfinden), kann der Kontroller- 12 Informationen 



empfangen, die nicht mehr aktuell sind, und zwar zu dem 
Zeitpunkt, wenn sie den Kontroller 12 erreichen. In ahnli- 
cher Weise hat der Kontroller 12 keine Moglichkeit zu be- 
stimmen, welche Daten es zu einem spezifischen Zeitpunkt 

5 sein sollen oder waren, was bei der Steuerung anderer Vor- 
richtungen innerhalb des Prozesses 19 wichtig sein kann, die 
nicht an den Bus 42 angeschlossen sind. Daruber hinaus 
kann es schwierig oder unmoglich fur den Kontroller 12 
sein, wichtige Informationen zu empfangen, die den Status 

10 einer Vorrichtung oder eihes Funktionsbiockes betreffen, 
und zwar innerhalb des Fieldbus-Abschnitts des Prozesses 
* 19, wie beispielsweise Alarme, die durch solche Funktions- 
biocke erzeugt werden. 

Um diese Probleme zu uberwinden, kann der Kontroller 

15 12 so ausgelegt sein, um die Schattenfunktionsblocke zu 
verwenden, um die Kommunikation mit den Vorrichtungen 
und den Funktionsblocken innerhalb des Fieldbus-Ab- 
schnitts des ProzeBregelnetzwerks 10 zu implementieren. 
Spezieller gesagt, kann die Steuerroutine innerhalb des 

20 Kontrollers 12 direkt mit einem Schattenfunktionsblock in- 
nerhalb des Kontrollers 12 kommunizieren, der dann auto- 
matisch mit einem zugeordneten aktuellen externen Funk- 
tionsblock N innerhalb einer Bereichsvorrichtung kommuni- 
ziert, die an den Bus 42 angeschlossen ist. Der Schatten- 

25 funktionsblock innerhalb des Kontrollers 12 ist so konrigu- 
riert, um den Stand der und die Daten, die dem aktuellen ex- 
ternen Funktionsblock zugeordnet sind, innerhalb einer Vor- 
richtung nach unten ( zu spiegeln, die an den Bus 42 ange- 
schlossen ist, so daB es fur die ProzeBsteuerroutinen inner- 

30 halb des Kontrollers 12 so scheint, als ob der tatsachliche 
externe Funktionsblock zugreifbar ist, ohne vermittels des 
Fieldbus-Protokolls iiber den Bus 42 kommunizieren zu 
miissen. Mit anderen Worten erscheint es fur die ProzeB- 
steuerroutine innerhalb des Kontrollers 12 so, als ob der tat- 

35 sachliche Funktionsblock innerhalb des ProzeBkontrollers 
12 gelegen ware, anstatt unten innerhalb einer externen Be- 
reichsvorrichtung, die an den Bus angeschlossen ist, und die 
ProzeBsteuerroutine verwendet den Schattenfunktionsblock 
so wie sie andere Funktionsblocke innerhalb des Kontrollers 

40 12 verwendet. 

Fig. 4 veranschaulicht eine graphische Einzelheit einer 
ProzeBregelschleife oder eines Moduls 100, der der ProzeB- 
steuerroutine zugeordnet ist und durch diese implementiert 
ist, und zwar innerhalb des ProzeBkontrollers 12. Um die 

45 Steuerung des gesamten Prozesses 19 zu implementieren, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des 
Kontrollers 12 viele solcher Schleifen oder Module imple- 
mentieren, die in irgendeiner gewiinschten Weise miteinan- 
der verbunden sein konnen. Die herausgegriffene ProzeBre- 

50 gelschleife 100 enthalt eine Representation eines Aspektes 
(Flusses) des Prozesses 101, der durch eine Anzahl von 
Kohtrollerblocken oder Einheiten gesteuert wird, speziell 
durch einen PID-Block 102, der an einen AO-Block 104, ei- 
nen ersten AI-Block 106 und einen zweiten AI-Block 108 

55 gekoppelt ist. Jeder der Blocke 102, 104 und 106 ist eine 
graphische Einzeldarstellung einer Regel subroutine (oder 
eines Objektes innerhalb einer objektprientierten Program- 
mierumgebung), die der ProzeBregelroutine zugeordnet ist, 
die in dem Kontroller 12 ge'speichert ist, konfiguriert gemaB 

60 einem KontroUerprotokoll, welches dem Kontroller 12 zu- 
geordnet ist und dazu verwendet wird, um einen Abschnitt 
. ' einer Gesamtregelstrategie in bezug auf den ProzeB 101 zu 
implementieren. Jeder der Blocke der ProzeBregelroutine 
100 enthalt Eingange und Ausgange (durch Eingange auf 

65 der linken und rechten Seite der Blocke jeweils veranschau- 
licht) und kann einen Steuer- oder Regelalgorithmus enthal- 
ten, der eine gewisse Steuer- oder Regelfunktion durchfuhrt. 
Verbindungen untereinander oder Verbindungen zwischen 
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den Funktionsblocken sind als Leitungen oder Linien darge- 
stellt, die von einem Ausgang von einem Block zu' einem 
Eingang eines anderen Blocks verlaufen. Diese Verbindun- 
gen geben die Art wieder, in welcher die Kommunikation 
zwischen den eirizelnen Blocken innerhalb der Steuerrou- 
tine oder Modul implementiert wird, um eine ProzeBregel- 
schleife gemaB einem Kontrollerprotokoll auszufuhren. So- 
mit veranschaulicht die Einzelheit von Fig. 4 nicht nur die 
Elemente der Regelschleife, die ausgef iihrt werden, sondern 
auch die Art, in welcher die ProzeBregelroutine innerhalb 
des Kontrollers 12 ausgelegt ist, um diese Schleife zu imple^ 
mentieren. Die ProzeBregelroutine kann automatisch gean- 
dert oder erneut konfiguriert werden, und zwar durch Bewe- 
gen der Verbindungen zwischen den Blocken, durch Addie- 
ren oder Weglassen von Blocken davon usw., wie dies durch 
den Delta V-ProzeBkontroller ausgefuhrt wird. 

Der PID-Funktionsblock 102, der in Fig. 4 veranschau- 
Ucht ist, enthalt einen Algorithmus (durch den Kontroller 12 
impiernentiert), der beispielsweise eine Proportional/Inte- 
gral/Differential-Regelberechnung ausfuhrt, basierend auf 
den EingangsgroBen, die er von den AI-B16cken 106 und 
108 und dem AO-Block 104 empfangt, und der ein Aus- 
gangssteuersignal fur den AO-Block 104 erzeugt, welcher 
seinerseits eine Vorrichtung (28 beispielsweise ein Ventil) 
innerhalb des Prozesses 101 veranlaBt, eineFunktion durch- 
zufuhren, wie beispielsweise bewirken, daB ein Ventil be- 
wegt wird, um die Stromung eines Mediums zu erhohen. 
Der AO-Block 104 kann einem tatsachlichen Ventil zuge- 
ordnet sein und dieses steuern, z. B. das Ventil 28 von Fig. 1, 
und zwar uber die IO- Vorrichtung 20 und die 4-20-mA- 
Konimunikationsleitung 38. Der AO-Block 104 empfangt 
■ eine Messung der tatsachlichen Position des Ventils und he- 
fert diese Messung als eine RiickkopplungsgroBe zu dem 
PID-Funktionsblock 102 iiber die Verbindung 110. Daruber 
hinaus empfangt der PID-Funktionsblock 102 Eingangsgro- 
Ben von dem AI-Block 106, der beispielsweise einem Sen- 
sor, wie einem Temperatursensor, zugeordnet ist, der inner- 
halb des Prozesses 19 gelegen ist. Dieser Sensor kann bei- 
spielsweise der Sensor 34 von Fig. 1 sein, in welchem Fall 
der AI-Block 106 die SensormeBgroBen iiber die I/O- Vor- 
richtung 22 empfangt, und zwar unter Verwendung von 
Standardnachrichtenubertragungen. Solch eine Verbindung 
ist in Fig. 4 durch die Verbindung zwischen dem Ausgang, 
der mit "FluB" in dem ProzeB 101 bezeichnet ist, und dem 
Eingang des AI-Blocks 106, der mit "simulate_in" bezeich- 
net ist, veranschaulicht. Die Verarbeitung und die Steuerung 
der Information, die dem PID-Funktionsblock 102, dem 
AO-Block 104 und dem AT-Block 106 zugeordnet ist, wird 
innerhalb des Kontrollers 12 durchgefuhrt. 

Allgemein gesagt, ist innerhalb des Delta V-Steuersy- 
• stems, das heiBt Verwendung des Delta V-Kontrollerkonfi- 
gurationsprotokolls jeder der Blocke 102, 104 und 106 spe- 
zifisch konfiguriert, um all die Informationen und Daten zu 
' unterstutzen, die den ahnlichen Funktionsblocken in dem 
Fieldbus-Protokoll zugeordnet sind und somit fur alle Ab- 
sichten und Zwecke, und ist sehr ahnlich einem Funktions- 
' block innerhalb des Fieldbus-Protokolls mit der Ausnahme, 
' daB die Steuerfunktionen oder Regelfunktionen durch den 
zentralen Prozessor 12 durchgefuhrt werden und daB die In- 
formationen von speziellen Bereichsvorrichtungen uber 
Standardkommunikationsleitungen von dem ProzeBkontrol- 
ler 12 empfangen und iibergeben werden. Somit smd die 
Abschnitte der Steuer- oder Regelroutine, die in Fig. 4 her- 
ausgegriffen ist, welche die Blocke 102, 104 und 106 ent- 
halt, momenta* in der Delta V-Umgebung vqrgesehen und 

sindbekannt ■ ^ 

Um dieFieldbus-Integration innerhalb des Kontrollers IZ 
zu unterstutzen, kann die folgende Annaherung versucht 



werden, urid zwar unter Verwendung eines Delta V-Steuer- 
systems- (oder eines anderen zentralisierten Steuersystems), , 
bei dem der Basissatz an Funktionsblocken, die in dem 
Steuersystem oder Regelsystem verwendet werden, ahnlich 
5 denjenigen ist, die durch das Fieldbus-Protokoll definiert 
sind. Die externen Fieldbus- oder herstellerspezifischen 
Funktionsblocke sind individuell zugeordnet, um in Verbin- 
dung mit dem Steuer- oder Regelsystem (oder einem TeiL 
des Steuer- oder Regelsy stems) ein Programm auszufuhren 
10 und die Funktionsblocke der Fieldbus- Vorrichtungen sind in 
dem Steuer- oder Regelsystem als Schattenfunktionsblocke 
wiedergegeben oder reflektiert, welche interne und exteme 
Referenzen unterstutzen, so als ob die externen Funktions- 
blocke in dem Steuer- oder Regelsystem vorhanden waren. 
15 Das Steuer- oder Regelsystem erneuert automatisch die dy- 
namischen und die statischen Parameter des Schattenfunkti- 
onsblocks und leitet Anderungsanfragen zu den geeigneten 
externen Funktionsblocken unter Verwendung der Schatten- 
funktionsblocke. Alarmsignaie, die in den externen Vornch- 
20 tungen (oder Funktionsblocken) detektiert werden, werden 
in den Schattenfunktionsblocken reflektiert und werden in 
der Alarmverarbeitung des Steuer- oder Regelsystems mte- 
griert. Naturlich kommuniziert der Schattenfunktionsblock 
mit den externen Funktionsblocken unter Verwendung des 
25 KontroUerprotokolls, welches den externen Funktionsblok- 
ken zugeordnet ist, welches verschiederi von dem Kontrol- 
lerkonfigurationsprotokoU sein kann und typischerweise 
verschieden ist, welches von dem Kontroller verwendet 
wird, um die Kommunikationen zwischen den Funktions- 
30 blocken intern zu dem Kontroller zu implementieren. Auch 
konnen Verbindungen zwischen internen und externen 
Funktionsblocken durch deh Anwender in einer Weise be- 
. stimmt werden, die davon abhangt, wo der Funktionsblock 
vorhanden ist. Als ein Ergebnis erscheinen wahrend der 
35' Steuerdefinition und der Online-Diagnose die FunkUons- 
blocke als die gleichen, ob sie nun interne (m dem Steuer- 
oder Regelsystem vorhanden) oder externe (in einer Field- 
bus- Vorrichtung vorhanden) sind oder nicht. 

Somit ist gemaB der vorliegenden Erfindung der AI- 
40 Block 108, der in Fig. 4 so dargestellt ist, daB er ahnlich dem 
AI-Block 106 ist, tatsachlich ein Schattenfunktionsblock, 
der so konfiguriert ist, daB er mit einem externen Funktions- 
block 112 kommuniziert, der beispielsweise innerhalb des 
Sensors 48 gelegen ist, der an den Fieldbus 42 von Fig. 1 an- 
45 geschlossen ist. Der Schattenfunktionsblock 108 liefert ge- 
messene oder andere Signale, die dem externen Funktions-. 
block 112 zugeordnet sind, an den PID-Block 102 iiber die 
Verbindungen, die dazwischen erstellt wurden. Um anzuzei- 
gen daB der Block 108 ein Schattenfunktionsblock ist, der 
50 einem externen Funktionsblock 112 zugeordnet ist und mit 
diesem kommuniziert,' unter Verwendung des,Kornmumka- 
tionsprotokolls des externen Funktionsblockes 112, ist der 
Block 108 so dargestellt, daB er eine strichHerte Lime be- 
sitzt, die an den AI-Funktionsblock 112 innerhalb der Field- 
55 bus-Vorrichtung 48 angehangt ist. Jedoch kann der Schat- 
tenfunktionsblock 108 so dargestellt sein, daB er eine Vor- 
richtungsetikette (device tag) und/oder einen Blocknamen 
am Boden desselben besitzt, oder kann in irgendeiner ande- 
ren gewunschten Weise dargestellt sein, wobei darauf hinge- 
60 wiesen sei, daB die Art, in welcher der Schattenfunktions- 
block fur einen Anwender als Einzelheit dargestellt ist, nicht 
kritisch ist, und zwar in Verbindung mit dem Betrieb des 
Schattenfunktionsblocks. Ferner werden die Eingangsgro- 
Ben und AusgangsgroBen, die dem AI-Funktionsblock 112 
65 zugeordnet sind, innerhalb des Fieldbus-Netzwerks gemaB 
dem Weg iibergeben, in welchem das Netzwerk konfiguriert 
wordenist. " . 

Wahrend der Schattenfunktionsblock 108 auf alle oder 
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die meisten der Informationen zugreift oder spiegelt, die 
dem tatsachlichen Funktionsblock 112 zugeordnet sind und/ 
oder durch diesen erzeugt werden, erfolgt irgendeine Verar- 
beitung, die in bezug auf die AI-Funktionsblock 112 stattfin- 
det (oder in. bezug auf irgendeinen anderen Funktionsblock, 
flir den ein Schattenfunktionsblock existiert) in dieser Weise 
unten in der externen Vorrichtung, nicht in dem Schatten- 
funktionsblock 108 oder selbst in dem Kontroller 12. Als ein 
Ergebnis kann der Schattenfunktionsblock 108 so betrachtet 
werden, als ob er eine Rohre von Informationen zwischen 
dem PID-Block 102 (oder irgendeinem anderen Block in- 
nerhalb des zentralisierten Kontrollers 12) urid dem tatsach- 
lichen Funktionsblock 112 bilden wiirde. Der Schattenfunk- 
tionsblock 108 ist nicht ein Funktionsblock, der vollstandig 
durch den Kontroller 12 betreibbar ist, in dem Sinn, daB der 
AI-Block 106 und der PID-Block 102 durch den Kontroller 
12 betreibbar sind, da der Schattenfunktionsblock 108 ledig- 
lich die Informationen innerhalb des tatsachlichen externen 
Funktionsblocks 112 spiegelt oder ansonsten eine Nachrich- 
tenubertragung zwischen dem Kontroller 12 und dem tat- 
sachlichen externen Funktionsblock 112 vorsieht. Nichtsde- 
stoweniger kann durch eine geeignete Operation des Schat- 
tenfunktionsblockes der Kontroller 12 den tatsachlichen 
Funktionsblock 112 steuern und mit diesem kommunizie- 
ren, so als ob dieser vollstandig in dem Kontroller 12 imple- 
mentiert ware. Indem beispielsweise eine Kommunikation 
mit dem Schattenfunktionsblock 108 durchgefuhrt wird, un- 
ter Verwendung des Kontrollerkonfigurationsprotokolls, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des . 
Kontrollers 12 auf den neuesten Stand gebrachte Informa- 
tionen von dem Funktionsblock 112 empfangen und kann 
Befehle zu dem Funktionsblock 112 so schnell wie moglich 
senden, ohne sich darum kummern zu miissen, wo der tat- 
sachiiche Funktionsblock 112 gelegen ist oder auf. welche 
Weise Kommunikationen mit dem tatsachlichen Funktions- 
■ block 112 bewirkt werden. Statt dessen erfolgen die Kom- 
munikationen zwischen dem tatsachlichen Funktionsblock 
. 112 und dem Schattenfunktionsblock 108 automatisch ohne 
Eihgreifen durch die ProzeBsteuerroutine, die lediglich die 
Schritte ausfuh'ren muB, die sie in typischer Weise ausfiihrt, 
urn die Kommunikationen zwischen den Steuer- oder Funk- 
tiqnsblocken zu implementieren,.die innerhalb des Kontrol- 
lers 12 gelegen sind. In dieser . Weise ermoglicht es der 
Schattenfunktionsblock einem Kontroller, der Funktions- 
bldcke innerhalb des Kontrollers implemehtiert, Funktions- 
blocke zu verwenden und mit zu ihtegrieren, die unter- 
schiedliche Kommunikations- oder Konfigurationsproto- 
kolle verwenden und die nicht innerhalb des Kontrollers ge- 
legen sind, sondern die statt dessen in einer externen Vor- 
richtung gelegen und in diese implementiert sind, wie bei- 
spielsweise einer mikroprozessor-unterstiitzten Bereichs- 
vorrichtung, die in eirier ProzeBumgebung angeordnet ist. 
Diese hinzugefiigte Fahigkeit wird von dem Kontroller 12 in 
transparenter Weise erreicht, so daB dann, sob aid der Schat- 
tenfunktionsblock in dem Kontroller 12 aufgebaut ist, die 
Steuer- oder Regelroutine nicht nachzusuchen braucht, wq 
der tatsachliche Funktionsblock gelegen ist, um komplexe 
Kommunikationen oder Datenbasismanipulationen durch- 
zufuhren, urn den externen Funktionsblock 112 zu verwen- 
den. -/ : / 

Wie hervorgeht, speichert der. Schattenfunktionsblock 
108 die EingangsgrdBen und AusgangsgroBen der parame- 
trischen Updates, die dem AI- Funktionsblock 112 in einer 
Datenbasis in dem Kontroller 12 zugeordnet sind, und zwar 
in irgendeinem gewiinschten Format, speichert jedpch in be- 
yorzugter Weise diese in dem gleichen oder einem ahnlichen 
Format wie die Informationen, die den Steuerblocken zuge- 
ordnet sind, die durch den kontroller implementiert sind, 
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das heiBt unter Verwendung des KontroUerkonfigurations- 
protokolls. Dies macht die Kommunikation mit dem Schat- 
tenfunktionsblock 108 fur den Kontroller 12 transparent, 
das heiBt die ProzeBsteuer- oder -regelroutine 100 schafft 

5 eine Kommunikation in bezug auf den Schattenfunktions- 
• block 108 (und somit mit dem tatsachlichen Funktionsblock 
. 112) uber die Verbindung in der gleichen Weise wie sie eine 
Kommunikation in bezug auf die anderen Funktionsblocke 
104 und 106 erzeugt. Wahrend es wunschenswert ist, daB 

10 die Funktionsblocke , innerhalb des Kontrollers 12 logisch 
konfiguriert sind, um all die Informationen (oder die mei- 
sten) zu unterstutzen, die durch das dezentralisierte oder ex- 
teme ProzeBregelnetzwerk uriterstiitzt werden (wie dies bei 
dem Delta V- Kontroller und dem Fieldbus-Kommunikati- 

15 onsprotokoll der Fall ist), so ist diese Konfiguration nicht er- 
forderlich. Tatsachlich kann irgendein Kontrolleraufbau un- 
ter Verwendung des Schattenfunktionsblockes unterstutzt 
werden, der hier offenbart ist, indem die Daten, die in dem 
externen Funktionsblock unterstutzt werden und in diesem 

20 verfiigbar sind, in den Daten abgebildet werden, . die in der 
Kontrollerroutine verwendet und verfiigbar sind. 

Allgemein gesagt, um den Betrieb des Schattenfunktions- 
blockes 108 in dem Fieldbus-Netzwerk zu bewirken, wird 
der tatsachliche Funktionsblock 112 so konfiguriert, um die 

25 verketteten Daten zu veroffentlichen und an den ProzeB kon- 
troller 12 (das heiBt die Daten, die mit einem anderen Block 
innerhalb des Kontrollers 12 uber eines der Verbindungs- 
glieder, die in Fig. 4 veranschaulicht sind, verbunden sind) 
oder zu veroffentlichen, und zwar uber die Schnittstellen- 

30 karte 40, unter Verwendung des Veroffentlicher/Teilnehmer- 
VCR's (das heiBt synchronen Kommunikationen) in dem 
Fieldbus-Kommunikationsprotokoll. Andere nicht verket- 
tete Daten, die dem tatsachlichen Funktionsblock 112 zuge- 
ordnet sind, werden an die Schnittstellenkarte 40 unter Ver- 

35 wendung von asynchronen Kommunikationen bzw. Nach- 
richtenubertragungen iibergeben, unter Verwendung von 
beispielsweise den Betrachtungsobjekt- oder Warnobjekt- 
funktionen innerhalb des Fieldbus-Protokolls, was in der 
Modulabtastrate des Steuermoduls innerhalb des Kontrol- 

40 lers 12 stattfindet. Es werden daher in typischer Weise ver- 
kettete Daten zu dem Kontroller 12 von dem Funktions- 
block 112 in einer sehr viel schnelleren Rate gesendet als an- 
dere Daten (weniger zeitsensitive Daten). Urngekehrt wer- 
den verkettete Daten, die durch einen Block innerhalb des 

45 Kontrollers 12 zu dem Schattenfunktionsblock 108 gesendet 
werden, unmittelbar an die Schnittstellenvorrichtung 40 
weitergeleitet, wo sie auf dem Fieldbus-Bus 42 unter Ver- 
wendung von synchronen Standardnachrichtenubertragun- 
gen veroffentlicht werden. 

50 Die Informationen, die von dem tatsachlichen Funktions- 
block 112 gesendet werden, werden automatisch in den 
Schattenfunktionsblock 108 gesetzt und stehen somit fur die 
Steuer- oder Regelroutine in dem Kontroller 12 zu jeder Zeit 
zur Verfugung. Um diese Operation zu bewirken, nimmt die 

55 Schnittstellenkarte 40 (die Teil eines Kommunikationsports 
des Schattenfunktionsblockes sein kann) teil an den verof- 
fentlichten Verbindungsparameterdaten, die durch den 
Funktionsblock 112 erzeugt wurden, und liefert diese Infor- 
mationen zu dem ProzeBkontroller 12 in der Rate, die durch 

60 die Ausfuhrungsrate des Funktionsblockes innerhalb des 
Makrozyklusses des Fieldbus-Segments festgelegt ist, an 
welches der externe Funktionsblock 112 angeschlossen ist. 
In ahnlicher Weise erhalt die Schnittstellenkarte 40 (die ty- 
pischerweise das LAS des Fieldbus-Segments ist) die Be- 

65 'trachtungsobjekte und/oder Wamobjekte des tatsachlichen 
Funktionsblocks in einer Rate, die durch die Abtastrate des 
Kontrollermoduls festgelegt ist, in welchem der Schatten- 
funktionsblock 108 vorhanden ist, das heiBt in der Rate, in 
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welcher die Steuer- oder Regelroutine 100 in dem Kontrol- 
ler 12 die Blocke implementiert, die dieser zugeordnet sind. 
Wie dies bekannt ist, enthalt das Fieldbus-Protokoll vier Ty- 
pen von Betrachtungsobjekten, die die normalerweise dyna- 
mischen (Betrachtungsobjekt 1), normalerweise statischen 
(Betrachtungsobjekt 2), alle dynamischen (Betrachtungsob- 
jekt 3) und alle statischen (Betrachtungsobjekt 4) Variablen 
speichern. Die Schnittstellenkarte 40 ist so konfiguriert, um 
automatisch auf einer periodischen Grundlage oder durch 
Aussenden einer Anfrage nach solchen Informationen das 
dynamische Betrachtungsobjekt 3 zu empfangen, welches 
die Werte far alle die dynamischen Variablen enthalt, die 
dem tatsachlichen Funktionsblock 112 zugeordnet sind. 
Nach Empfangen dieser Betrachtungsobjektinformationen 
speichert die SchnittsteUenkarte 40 die Informationen in ei- 
ner Datenbasis oder Datenbank, die durch den Schatten- 
funktionsblock zugreifbar ist, und der .Schattenfunktions- 
block 108 emeuert die- Variablen, die sich dadurch geandert 
haben, wodurch diese variablen Werte fur die ProzeBsteuer- 
oder -regelroutine innerhalb des Kontrollers 12 verfugbar 
werden. Wenn eine der dynamischen Variablen (die stati- 
sche Revisionsvariable) eine Anderung an einer statischen 
Variablen anzeigt, kann der Schattenfunktionsblock oder die 
Software innerhalb der Schnittstellenkarte 40 anfragen, daB 
das Betrachtungsobjekt 4 (alle statischen Variablen) zu dem 
Schattenfunktionsblock 108 gesendet werden, um die stati- 
schen Variablen auf den neuesten Stand zu bringen. Bei der 
bevorzugten Ausfuhrungsform empfangt die Hl-Schnitt- 
stellenkarte 40 fortlaufend das Betrachtungsobjekt 3 in der 
Modulabtastrate des Steuermoduls 100 innerhalb des Kon- 
trollers^. 

Wie oben dargelegt ist, kann der Kontroller 12 (oder ir- 
gendein Funktionsblock desseiben) Befehle zu dem aktuel- 
len Funktionsblock 112 innerhalb des Fieldbus-Netzwerks 
uber den Schattenfunktionsblock 108 einfach dadurch sen- 
den, indem ein Parameter innerhalb des Schattenfunktions- 
blockes 108 geandert wird. Diese Parameteranderung wird 
automatisch nach unten zu dem AI-Funktionsblock 112 uber 
■ einen Ausgang des Schattenfunktionsblockes 108 gesendet, 
wo er dazu verwendet wird, um die Konfiguration des AI- 
Funktionsblockes 112 zu andern. Wahrend die Datenande- 
rung oder der Einschreibbefehl in dem tatsachlichen Funk- 
tionsblock 112 nicht zu exakt der gleichen Zeit durchgefuhrt 
wird, zu der dieser durch den Schattenfunktionsblock 108 
.empfangen wird, und zwar vom StandpUnkt des Kontrollers 
12 aus, erfolgt diese Anderung sehr schnell und wird in den 
Schattenfunktionsblock 108 zuruck reflektiert, wenn die 
Anderung tatsachlich vorgenommen wurde. Diese Betriebs- 
weise ermoglicht es dem Kontroller 12 und speziell dem' 
PID-Funktionsblock 102, innerhalb des Kontrollers 12 eine 
Anderung zu bewirken, indem lediglich diese Anderung in 
eine Speicherstelle eingeschrieben wird, die dem Schatten- 
funktionsblock 108 zugeordnet ist und indem danach die 
Kommunikation automatisch vorgenommen wird, ohne daB 
dabei irgendwelche speziellen Kommunikationsaktivitaten 
ausgefiihrt werden miissen, die erforderlich sind, um Daten 
in das Fieldbus-Netzwerk hinein zu bekommen und heraus 
zu bekommen. 

Neben den Eingangs- und Ausgangsparameterdaten kon- 
nen andere Typen von Daten, wie beispielsweise Modus- 
und Statusdaten, zwischen einem Kontrollerfunktionsblock 
(das heiBt einem intemen Funktionsblock) und dem Schat- 
tenfunktionsblock 108 iibertragen werden als auch zwischen 
dem Schattenfunktionsblock 108 und dem tatsachlichen ex- 
ternen Funktionsblock 112. Naturlich wird diese Informa- 
tion mit den Betrachtungsobjekt- oder Wamobjektinforma- 
tionen von dem externen Funktionsblock 112 zu denTSchat- 
tenfunktionsblock 108 gesendet. In ahnlicher Weise konnen 



solche Modus- und Statusdaten an den Schattenfunktions- 
block 108 von einem internen Funktionsblock innerhalb des . 
Kontrollers 12 ubermittelt werden und es konnen diese Da- 
ten dann an den externen Funktionsblock 112 fur die Ver- 
5 wendung geliefert werden. Der Statusparameter eines Funk- 
tionsblockes zeigt in typischer Weise die Qualitat der Mes- 
sung oder der Daten an, die durch den Funktionsblock gelie- 
fert werden, und kann Grunde liefern, warum eine schlechte 
Qualitat existiert. Er kann auch eine Grenze anzeigen, wie 
10 beispielsweise eine hohe oder niedrige Grenze, welche die 
Daten erreichen konnen. Der Modusparameter zeigt in typi- 
scher Weise an, welcher Modus des Funktionsblocks einge- 
schaltet ist, welcher beispielsweise ein Handmodus, ein Au- 
tomatikmodus oder ein Kaskadenmodus sein kann, wie dies 
15 durch das Fieldbus-Protokoll festgelegt ist. 

Daruber hinaus wird eine Alarmdetektion basierend auf 
Alarmsignalen, die in dem tatsachlichen externen Funk- 
tionsblock erzeugt werden, vorgesehen, da Ereignisse und 
Berichte durch den externen Funktionsblock automatisch als 
20 dynamische Parameter erzeugt werden, die dann durch die 
Betrachtungs- oder Wamobjekte dem Schattenfunktions- 
block 108 angeboten werden. Als ein Ergebnis kann eine 
• Alarminformation, die den externen Funktionsblock betrifft, 
von dem Kontroller 12 betrachtet und verwendet werden. 
25 . Obwohl naturlich der Block 108 hier als Schattenfunkti- 
onsblock beschrieben wurde, konnen irgendwelche Blocke 
innerhalb der Fig. 4 ebenfalls oder alternativ Schattenfunk- 
tionsblocke sein. 

Die Vorteile, die mit der Verwendung eines Schattenfunk- 
30 tionsblockes verbunden sind, wie beispielsweise dem Schat- 
tenfunktionsblock 108, der in Fig. 4 veranschaulicht ist, be- 
stehen darin, daB dieser es dem ProzeBregeldesigner ermog- 
licht, die Steuerung oder Regelung innerhalb eines zentrali- 
sierten ProzeBkontrollers 12 zu implementieren unter Ver- 
35 wendung von externen Funktionsblocken, das heiBt Funk- 
tionsblocken, die tatsachlich innerhalb einer verschiedenen 
Vorrichtung implementiert sind und die unterschiedlichen 
Kommunikationsprotokollen unterworfen sind. In Verbin- 
dung mit dem Schattenfunktionsblock braucht ein Designer 
40 oder Konstrukteur sich nicht darum zu kummern, daB der 
externeFunktionsblock einem unterschiedlichen Kommuni- 
kations- oder Steuer- oder Regelprotokoil zugeordnet ist 
oder in einer unterschiedlichen Vorrichtung gelegen ist, da 
die Nachrichteniibermittlung zwischen dem Schattenfunkti- 
45 onsblock und dem externen Funktionsblock automatisch er- 
folgt und auch transparent fur die Steuer- oder Regelroutine. 
Wenn ferner einmal ein Schattenfunktionsblock implemen- 
tiert ist und lauft, ist es einfach ein Modell daruber zu erstel- 
len, was sich innerhalb des gesamten ProzeBregelsystems 
50 ereignet, und zwar ohne sich darum zu kummern, ob Aktio- 
. nen innerhalb einer Fieldbus- oder anderen externen Vor- 
richtung auftreten oder innerhalb des Kontrollers auftreten, 
da der Schattenfunktionsblock fur den Kontroller und den 
Anwender bewirkt, daB es so scheint, daB der tatsachliche 
55 Funktionsblock in dem Kontroller implementiert ist, obwohl 
dies real nicht der Fall ist. • 

Wenn ein gemeinsamer Funktionsblocksatz und Schatten- 
funktionsblocke in dem Steuer- oder Regelsystem verwen- 
det werden, um Funktionsblocke wiederzugeben, die exter- 
60 nen Vorrichtungen zugeordnet sind, kann die Steuer- oder 
Regelstrategie zu Beginn ohne das Wissen ausgelegt wer- 
den, ob ein bestimmter Funktionsblock dieser Strategie in 
dem Steuer- oder Regelsystem vorhanden sein wird oder in 
einer externen Vorrichtung vorhanden sein wird, und es kon- 
65 hen Anwenderanwendungen auf die Schattenfunktions- 
blocke zugreifen (welche die externen Funktionsblocke wie- 
dergeben oder als Modell darstellen), und zwar in exakt der 
gleichen Weise wie sie auf die Steuer- oder Regelsystem- 
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funktionsblocke zugreifen. Auch werden Alarme, die durch 
die exteme Vorrichtung detektiert werdea, voll in die Steu- 
ersystemalarmverarbeitung durch den Schattenblock inte- 
griert, mit der Moglichkeit, daB diese Alarme in exakt der 
gleichen Weise fiir die externen Funktionsblocke erscheinen 
wie fur Funktionsblocke, die innerhalb des Steuer- oder Re- 
gelsystems vorhanden sind. 

Die Konfiguration, Implementierung und Verwendung ei- 
nes Schattenfunktionsblockes wird nunmehr in Einzelheiten 
unter Hinweis auf die Fig. 5-13 beschrieben. Fig. 5 veran- 
schaulicht den physikalischen Aufbau eines Abschnitts des 
ProzeBregelnetzwerks von Fig. 1 mehr in Einzelheiten. Die 
Anwenderworkstation 150, die aus irgendeinem der PCs 14 
von Fig. 1 bestehen kanh, ist kommunikativ mit dern Kon- 
iroller 12 verbunden, der seinerseits uber die Schnittstellen- 
karte 40 mit der Bereichs vorrichtung 48 verbunden ist, wel- 
che den Funktionsblock 112 darin enthalt. Wie in Fig. 5 ver- 
anschaulicht ist, besitzt der Kontroller 12 einen oberen Ab- 
schnitt 152, in welchem die Steuerroutine 100 (enthaltend 
den Schattenfunktionsblock 108) implementiert ist, und ei- 
nen unteren Abschnitt, der eine Datenbasis oder Datenbank 
156 enthalt, um'Eingangs- und Ausgangsinformationen zu 
speichern, die von der Schnittstellenkarte 40 als auch von 
anderen I/O-Karteri empfangen werden. Allgemein gesagt, 
ist die Schnittstellenkarte 40 so konfiguriert, um automa- 
tisch verkettefe Daten zu empfangen, die durch den Funk- 
tionsblock 112 veroffentlicht werden, und zwar iiber den 
Veroffentlicher/Teilnehmer-VCR (in der Veroffentlichungs- 
rate, die durch den Makrozyklus des Fieldbus-Busses 42 
festgelegt ist), und um diese Daten in der unteren Datenbank 
156 zu speichern, wo sie dem Schattenfunktionsblock 108 in 
l der Abtastrate des Steuermodus 100 innerhalb des Kontrol- 
lers i2 angeboten werden. In ahnlicher Weise ist die Schnitt- 
stellenkarte 40 so konfiguriert, um die verketteten Daten, die 
durch einen Funktionsblock innerhalb des Kontrollers 12 er- 
zeugt werden, auf dem Fieldbus-Bus 40 zu veroffentlichen, 
unter Verwendung synchroner Nachrichteniibermittlungen 
innerhalb des Fieldbus-Netzwerks. Auch ist die Schnittstel- 
lenkarte 40 so konfiguriert, um periodisch anzufragen nach 
(unter Verwendung asynchroner Nachrichtenubertragun- 
gen) Betrachtungs- und/oder Alarmdaten von dem Funk- 
tionsblock 112 und um diese Informationen in der unteren 
Datenbank 156 zu speichern, um sie an den Schattenfunkti- 
onsblock 108 in der Abtastrate des Kontrollermoduls 100 zu 
liefern. 

Die Schnittstellenkarte 40 und/oder die Datenbasis 156 
kann einen Kommunikationsport des Schattenfunktions- 
blockes 108 umfasseri, kann Teil von diesem sein oder kann 
durch diesen gesteuert sein, der Kommunikationen zwi- 
schen dem Schattenfunktionsblock 108 und dem externen 
Funktionsblock 112 implementiert. Der Kommunikations- 
port enthalt einen Eingang, der von dem externen Funk- 
tionsblock 112 Daten empfangt, und zwar unter Verwen- 
dung des Kommunikationsprotokolls des externen Funk- 
tionsblocks 112, und enthalt einen Ausgang, der mit dem ex- 
ternen Funktionsblock 112 in Verbindung stent, um Daten 
(inklusive Schreibbefehlen) an den externen Funktionsblock 
112 unter Verwendung des Kommunikationsprotokolls des 
externen Funktionsb locks 112 zu senden. Natiirlich kann der 
Kommunikationsport des Schattenfunktionsblocks 108 in 
der Software und/oder einer anderen Hardware in dem Kon- 
troller zusatzlich oder in Verbindung mit der Schnittstellen- 
karte 40 und der Datenbank 156 implementiert sein. 

Um eine Steuer- oder Regelroutine unter Verwendung ei- 
nes Schattenfunktionsblocks zu konfigurieren, kann ein An- 
wender bei der Workstation 150 irgendwelche Standard- 
werkzeuge verwenden, wie beispielsweise solche, die durch 
das Delta V- Steuer- oder -Regelsystem geschaffen werden, 



um zu Beginn das ProzeBregelsystem zu konfigurieren. Im 
allgemeinen ermoglichen es die Delta V-Konfigurations- 
werkzeuge einem Anwender, Blocke darzustellen, zu konfi- 
gurieren und miteinander zu verbinden, wie beispielsweise 
5 diejenigen, die in Fig. 4 veranschaulicht sind, um eine oder 
mehrere Regelschleifen zu implementieren oder zu konstru- 
ieren oder Module, die der Steuer- oder Regelroutine zuge- 
ordnet sind. Zum Zwecke der Erlauterung kann die Steuer- 
routine zum Steuern eines Prozesses irgendeine Anzahl von 

10 Modulen enthalten, von denen jeder irgendeine Anzahl von 
gewunschten Blocken enthalten kann, die eine Anzahl von 
Regelschleifen implementieren. Wahrend der Konfiguration 
oder der Konstruktion eines ProzeBregelmoduls kann ein 
Anwender die Verwendung eines Funktionsblocks auswah- 

15 len, der innerhalb einer Vorrichtung extern zum Kontroller 
12 gelegen ist (wie beispielsweise einen Funktionsblock in- 
nerhalb einer der Fieldbus- Vorrichtungen des ProzeBregei- 
, systems). In diesem Fall kann das Konfigurationswerkzeug, 
welches dem Kontroller 12 zugeordnet ist, so konstruiert 

20 sein, um den Anwender zu fragen, die physikalischen der 
Verbindungen der Vorrichtung zu dem Kontroller 12 zu spe- 
zifizieren und andere Vorrichtungs- und Funktionsblock- 
konfigurationsinformationen zu spezifizieren, die fur die an-, 
fangliche Konfiguration der Vorrichtung und/oder des Funk- 

25 tionsblockes innerhalb der Vorrichtung gemaB dem Kom- 
munikationsprotokoll dieser Vorrichtung erforderlich sind 
(z. B. das Fieldbus-Kommunikationsprotokoll). Der An- 
wender kann dann aufgefordert werden, diese Informatio- 
nen in irgendeiner gewunschten Weise. zu liefem, wie bei- 

30 spiels weise iiber die Verwendung von Dialogkastchen. Na- 
tiirlich hangt die exakte Information, die benotigt wird, von 
dem Typ der Vorrichtung und des Funktionsblockes ab, der 
speziflziert wird, wie dies von einem Fachmann in Verbin-' 
dung mit dem Vorrichtungsprotokoll, welches verwendet 

35 wird, wie beispielsweise dem Fieldbus-Protokoll, zu erken- 
nen ist. . 

Ein Weg, um zu spezifizieren, daB. ein Funktionsblock 
durch eine bestimmte externe Vorrichtung (wie beispiels- 
weise eine Fieldbus- Vorrichtung) zu implementieren ist, be- 

40 steht darin, den Anwender dazu zu bringen, den Funktions- 
block, der innerhalb einer externen Vorrichtung gelegen ist, 
zu spezifizieren, unter Verwendung eines Browsers (oder ei- 
ner anderen Software) oder einer Liste oder durch Heraus- 
greifen der externen Vorrichtungen, die an den Kontroller 

45 angeschlossen sind, und dann Auswahlen von einer der auf- , 
gelisteten externen Vorrichtungen als die Vorrichtung, in 
welcher der Funktionsblock zu implementieren ist. Ein an- 
• derer Weg besteht darin, den Funktionsblock auf dem Bild- 
schirm auszuwahlen und dann diesen Funktionsblock auf 

50 eine Einzelheit eines Blocks in einer externen Vorrichtung 
durch Drag and Drop zu bewegen. Irgendeine dieser oder ir- 
gendeine andere gewiinschte Aktiori kann dem Konfigurati- 
onswerkzeug mitteilen, daB der Funktionsblock, der imple- 
mentiert werden soil, innerhalb der externen Vorrichtung 

55 liegt, und kann das Konfigurationswerkzeug veranlassen, 
den Anwender nach der spezifischen Vorrichtung und den 
Funktionsblockkonfigurationsinformationen zu fragen, die 
erforderlich sind, um den speziellen extemen Funktions- 
block zu konfigurieren und auf diesen zuzugreifen. Beide 

60 : diese Verfahren ermoglichen es einem Anwender, einen 
Funktionsblock in einer extemen Vorrichtung aus einer Li- 
ste von externen Vorrichtungen fur die Ausfuhrung eines 
Programms auszuwahlen. 

Wenn der Anwender speziflziert, daB ein externer Funk- 

65 tionsblock zu verwenden ist (das heiBt extern vom Kontrol- 
ler 12), . so erstellt die Konfigurationsroutine dann einen 
Schattenfunktionsblock in dem Kontroller und unternimmt 
Schritte, um die Fieldbus- Vorrichtung und den Funktions- 
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block innerhalb der Vorrichtung zu konfigurieren, wie dies 
im folgenden beschrieben wird. NatiirHch erlaubt es das 
Konfigurationswerkzeug in bevorzugter Weise dem Anwen- 
der, alle die Blocke, die zu verwenden sind, zu spezifizieren, 
ebenso die Ortlichkeiten oder Lagen solcher Blocke (das 
heiBt, ob irgendein Block in externen Vorrichtungen gelegen 
ist) und auch die Verbindungen zwischen den Blocken, be- 
vor die Schattenblocke implementiert werden und die exter- 
nen (z. B. Fieldbus-) Vorrichtungen initialisiert werden. Dies 
ermoglicht es, die Konfiguration des externen Netzwerks 
einmal auszufuhren, nach derii die Ortlichkeit oder Lage von 
alien den Blocken und auch die Natur yon alien Verbindun- 
gen zwischen den Funktionsblocken spezifiziert worden ist. 

In Verbindung mit der Befahigung des Kontrollers, die 
Parameterdaten fur die Funktionsblocke innerhalb der exter- 
nen Vorrichtungen einzusehen oder Zugriff auf diese zu ha- 
ben (iiber den Schattenfunktionsblock), kann die Schnitt- 
' stellenkarte 40 auch Vorrichtungs- und Segmentstatusinfor- 
mationen an den Kontroller fur Diagnosezwecke liefern. Die 
Schnittstellenkarte 40 kann beispielsweise eine Liste emp- 
fangen, die eine Identifikation der Vorrichtungen enthalt, die 
angenornmenermaBen an einem bestimmten Abschnitt oder 
Segment des Fieldbus-Netzwerks angehangt oder ange- 
schlossen sind, und sachdienliche Informationen iiber jede 
der identiflzierten Vorrichtungen enthalten. Die Schnittstel- 
lenkarte 40 kann dann periodisch Informationen (iiber syn- 
chrone oder asynchrone Nachrichtenverbindungen) erhal- 
ten, welche die Vorrichtungen betreffen, die tatsachlich an 
das Fieldbus-Segment angeschlossen sind oder die das Seg- 
ment selbst betreffen, und kann diese Informationen mit den 
Informationen innerhalb der. empfangenen Liste verglei- 
chen. Auf diese Weise kann die Schnittstellenkarte 40 be- 
stimmen, ob die Bereichsvorrichtungen fehlen oder nicht an 
das Fieldbus-Netzwerk angeschlossen sind, ob falsche Be- 
reichsvorrichtungen an das Fieldbus-Netzwerk angeschlos- 
sen sind, ob eine Bereichsvorrichtung sich dem Service ent- 
zieht, usw. In ahnlicher Weise kann die Schnittstellenkarte 
40 bestimmen, ob Segment wertprobleme auftreten, so als ob 
keine Nachrichtenverbindung iiber den Fieldbus-Bus exi- 
stiert. Wenn es gewiinscht wird, kann die Schnittstellenkarte 
40 diese Vorrichtungs- und Segmentstatusdaten an den Kon- 
troller (oder andere Vorrichtung) fur Diagnosezwecke sen- 
den. 

Ferner kann die Schnittstellenkarte 40 die Kommunika- 
tion und den Zeitsteuerstatus eines Fieldbus-Segments fiir 
Diagnosezwecke uberwachen. Insbesondere kann die 
Schnittstellenkarte 40 automatisch an den Daten teilhaben, 
die durch die Bereichsvorrichtungen auf dem Fieldbus-Bus 
veroffentlicht werden, und kann die empfangenen Daten 
analysieren, um beispielsweise Zeitsteuerprobleme oder an- 
dere Probleme auf dem Fieldbus-Bus zu ermitteln. Wenn es 
gewiinscht wird, kann die Schnittstellenkarte 40 die ankom- 
menden Daten zeitlich pragen und speichern und dann Stati- 
stiken aufbewahren, die jedeh Funktionsblock oder Vorrich- 
tung betreffen, der oder die an den Bus angeschlossen ist 
undVoder Statistiken aufbewahren, die das Segment des Bus- 
ses betreffen. Beispielsweise kann die Schnittstellenkarte 40 
die minimalen und maximalen Zeiten zwischen Datener- 
neuerungen bestimmen, und zwar fiir bestimmte publizierte 
Daten, und kann bestimmen, ob diese Zeiten innerhalb eines 
zulassigen Bereiches liegen, um festzustellen, ob Kommuni- 
kationsprobleme existieren. In ahnlicher Weise .kann die 
Schnittstellenkarte 40 die Zeiten, zu welchen bestimmte Da- 
ten angenornmenermaBen auf dem Bus zu veroffentlichen 
sind, mit der tatsachlichen Zeit vergleichen, zu welcher 
diese Daten auf dem Bus veroffentlicht werden, kann ver- 
brauchte Datenzahlwerte fur die Funktionsblocke oder Vor- 
richtungen iiberwachen und kann irgendwelche anderen ge- 
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wiinschten Statistiken aufbewahren, um Zeitsteuerungs- 
oder andere Kommunikationsfehler auf dem Bus zu detek- 
tieren. Natiirlich konnen irgendwelche anderen publizierten 
Daten iiberwacht werden, um die Kommunikations- oder 
5 Zeitsteuerprobleme auf dem Bus zu bestimmen. Wie oben 
dargelegt wurde, konnen die statistischen Informationen, die 
durch die Schnittstellenkarte 40 erzeugt oder gespeichert 
werden, fiir irgendeinen Funktionsblock, Vorrichtung oder 
Segment des Busses aufbewahrt werden und konnen zu dem 
10 Kontroller (oder irgendeiner anderen Vorrichtung) fur Dia- 
gnosezwecke gesendet oder von dem Kontroller gelesen 
werden. 

Fig. 6 veranschaulicht ein RuBdiagramm 200, welches 
den Weg anzeigt, in welchem ein Schattenfunktionsblock 

15 innerhalb des Kontrollers 12 erstellt werden kann. Wahrend 
die RuBdiagramme der Fig. 6-12 eine Anzahl von Blocken 
veranschaulichen, sei darauf hingewiesen, daB diese Blocke 
lediglich eine Sequenz von Schritten angeben, die auszufuh- 
ren sind, und daB die Schritte in der Software oder in irgend- 

20 einer anderen gewiinschten Weise ausgefiihrt werden kon- 
nen. Die FluBdiagrammblocke der Fig. 6-12 stellen jedoch 
nicht notwendigerweise Funktionsblocke oder Kontroller- 
blocke dar, ahnliche den Funktionsblocken, die in Fig. 4 
veranschaulicht sind. ' 

25 Bei einem Block 201 empfangt der Kontroller 12 ein Mo- 
duHnstallationsskript von der Anwenderworkstation, die 
auf einem der PCs 14 von Fig. 1 bestehen kann. Das Modul- ' 
Installationsskript wird durch das Konfigurationswerkzeug . 
erzeugt, welches durch die Anwenderworkstation ablauft 

30 oder auf dieser Anwenderworkstation lauft, und enthalt alle 
Informationen, die erforderlich sind, um die Objekte (in ei- 
ner objektorientierten Programmiersprache) zu erstellen, die 
den Funktionsblocken eines Steuermoduls in dem Kontrol- 
ler 12 zugeordnet sind. Das heiBt, das Installationsskript 

35 konfiguriert die Blocke (wie beispielsweise die Funktions- 
blocke, die dem Steuermodul 100 von Fig. 4 zugeordnet 
sind) und die Verbindungen zwischen solchen Blocken, die 
durch die Verbindungen (Links) definiert sind. Natiirlich 
werden all diese Informationen durch den Anwender gelie- 

40 fert, wahrend dieser das Konfigurationswerkzeug verwen- 
det. Wenn ein Funktionsblock durch einen externen Funk- 
tionsblock zu implementieren ist, wie beispielsweise einen 
in einer Bereichsvorrichtung, erzeugt ein Block 202 einen 
Schattenfunktionsblock innerhalb des Kontroller 12, und 

45 zwar durch Erzeugen eines Objektes (innerhalb einer ob- 
jektorientierten Programmiersprache), welches ahnlich ist 
den Funktionsblocken fur andere Vorrichtungen, die inner- 
halb des Kontrollers gelegen sind, ausgenommenen dieses 
fuhrt keinerlei Steuerfunktionen durch. Wahrend die Schat- 

50 tenfunktionsblocke in bevorzugter Weise als ein Objekt in 
einer objektorientierten Programmierumgebung erzeugt 
werden, konnen sie unter Verwendung irgendeiner anderen 
Programmierumgebung erzeugt werden, die dem Kontroller 
12 zugeordnet ist oder von diesem verwendet wird. 

55 Wenn ein Schattenfunktionsblock aufgebaut wird, veran- 
laBt der Block 202 die Schnittstellenkarte 40, den tatsachli- 
chen Funktionsblock innerhalb der Fieldbus- Vorrichtung 
abzutasten und Informationen von dem tatsachlichen Funk- 
tionsblock zu erhalten, die erforderlich sind, um zu Beginn 

60 den Schattenfunktionsblock zu konfigurieren. Ferner erstellt 
der Block 202 die Datenbankstellen innerhalb der unteren 
Datenbank 156 des Kontrollers 12, an die die Schnittstellen- 
' karte 12 Betrachtungsobjekt- und Warnobjektdaten als auch 
verkettete Parameterdaten eingeben sollte, die von dem tat- 

65 sachlichen Funktionsblock erhalten werden. Der Block 202 
informiert auch die Schnittstelle 40 dariiber, wie oft Be- 
trachtungsobjekt- und Wamobjektinformationen basierend 
auf der Abtastrate des Moduls 100 angefragt werden sollen. 
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Nachdem der Block 202 einen Schattenfunktionsblock in 
dem Kontroller erzeugt hat und die geeigneten Verbindun- 
gen zwischen der Datenbank 156, dem Schattenfunktions- 
block 108 und der Schnittstellenkarte 40 identifiziert hat, 
konfiguriert ein Block 203 die untere Datenbasis 156, um 
die gespeicherten verketteten Parameterdaten (das heiBt die- 
jenigen, die durch die Schnittstellenkarte 40 unter Verwen- 
dung des synchronen VeroffentlicherATeilnehmer-VCRs er- 
halten wurden) an den Schattenfunktionsblock zu liefem, 
anstelle der Daten, die fur die verketteten Parameter unter 
Verwendung der Objektoperation erhalten werden. Dies ist 
erforderlich, um sicherzustellen, da6 die zuletzt erstellten 
Daten fur die verketteten Parameter (das heiBt diejenigen, 
die durch die synchronen Kommunikationen in dem Field- 
bus-Netzwerk erhalten wurden) dem Schattenfunktions- 
block 108 angeboten werden anstelle der Daten, die fur 
diese Parameter unter Verwendung der Betrachtungslisten- 
operation erhalten werden (was asynchron erfolgt); 

Wenn ein Steuermodul, der einen Schattenfunktionsblock 
verwendet, zu Beginn konfiguriert wird, mu8 das Fieldbus- 
Kommunikationsnetzwerk ebenfalls konfiguriert werden, 
um die erforderlichen synchronen und asynchronen Nach- 
richtenubertragungen zwischen dem aktuellen Funktions- 
, bloclc 112 und dem. Schattenfunktionsblock 108 zu unter- 
stiitzen. Die Fig, 7-12 veranschaulichen FluBdiagramme, 
welche die Schritte herausgreifen, die beim Konfigurieren 
des Fieldbus-Netzwerks involviert sind, um die Schatten- 
funktionsblocke zu unterstiitzen. Wahrend die Fig. 7-10 als 
getrennte HuBdiagrarnme dargestellt sind, konnen sie 
gleichzeitig oder nahezu gleichzeitig ausgefuhrt werden. 

Fig. 7 zeigt ein RuBdiagramm 210, welches dazu ver- 
wendet werden kann, einen verbindungsaktiven Plan oder 
Ablaufsteuening in dem Fieldbus-Netzwerk zu erstellen. 
Ein Block 211 innerhalb des Kontrollers 12 empfangt das 
LAS-Plan-Installationsskript, wie es durch das Konfigurati- 
onswerkzeug fur das Fieldbus-Kommunikationsnetzwerk 
entwickelt wurde, und zwar nach Inbetrachtziehung aller 
synchroner Nachrichteniibertragungen, die iiber den Field- 
bus-Bus stattfinden rntissen, inklusive solcher, die fur die 
Schattenfunktionsblocke erforderlich sind. Naturlich kann 
dieses Installationsskript unter Verwendung bekannter 
Werkzeuge erzeugt werden, die fur das Fieldbus-Kommuni- 
kationsprotokoll verfugbar sind, die auch in dem Konfigura- 
tionswerkzeug des Kontrollers 12 integriert sein konnen. 
Ein Block 212 installiert dann den LAS-Plan (Abwickler) an 
dem angepeilten Fieldbus-Port, der beispielsweise die 
Schnittstellenkarte 40 aus Fig. 5 sein kann. 

Danach erzeugt ein Block 213 automatisch Teilnehmer- 
verbindungen und VCRs innerhalb des Fieldbus-Netzwerks 
basierend auf den Daten, die durch die Fieldbus-Vorrichtun- 
gen veroffentlicht werden. Speziell werden diese Teilneh- 
merverbindungen derart erzeugt, daB die Schnittstellenkarte 
40 teil hat an den verketteten Parametern der Fieldbus- 
Funktionsblocke, fur Schattenfunktionsblocke innerhalb des 
Kontrollers 12 existieren. In ahnlicher Weise gibt die 
Schnittstellenkarte 40 Daten heraus, die durch die Funk- 
tionsblocke innerhalb des Kontrollers 12 erzeugt werden 
und die zu den Schattenfunktionsblocken innerhalb des 
Kontrollers, 12 als ein verketteter Parameter gesendet wer- 
den. AUgemein gesagt, agiert die Schnittstellenkarte 40 als 
ein Funktionsblock-Proxy fur die verketteten Daten zu und 
von den Schattenfunktionsblocken. Femer wirkt die Schnitt- 
stellenkarte 40 als ein Funktionsblock-Proxy, um nach Be- 
trachtungsobjekt- und Warnobjektinformationen von den 
tatsachlichen oder aktuellen Funktionsblocken anzufragen, 
fur welche Schattenfunktionsblocke existieren, um die nicht 
verketteten Daten zu emeuern, die den Schattenfunktions- 
blocken innerhalb des Kontrollers 12 zugeordnet sind. 



Ein Block 214 bildet dann den LAS-Installationsstatus in 
dem Kontroller (oder Delta V-)Status ab, so daB der Kontrol- 
ler 12 bestimmen kann, ob die LAS-Installation akzeptiert 
worden ist oder durch das Fieldbus-Netzwerk abgewiesen 
5 wurde. Dies ermoglicht es dem Kontroller 12 zu verifizie- 
*ren, ob die Installation des Fieldbus-Netzwerks stattgefun- 
den hat. 

Fig. 8 veranschaulicht ein RuBdiagramm 220, welches 
die Schritte zeigt, die dazu verwendet werden, um die Verof- 

10 fentlicher-Verbindungen innerhalb des Fieldbus-Netzwerks 
zu erstellen. Ein Block 221 in dem Kontroller 12 empfangt 
die Veroffentlicher-Verbindungen, die durch das Worksta- 
tion-Konfigurationswerkzeug fur das Fieldbus-Netzwerk er- . 

. zeugt wurden, und ein Block 222 seridet dann diese Verof- 

15 fentlicher-Verbindungen (publisher links) zu der Schnittstel- 
lenkarte 40, um die Veroffentlicher-Verbindungen zu erstel- 
len und auch die zugeordneten VCRs, die erforderlich sind, 
um die Schattenfunktionsblockkommunikationen als auch 
andere Kommunikationen auf dem Funktionsblock 42 zu 

20 unterstiitzen. 

Fig. 9 zeigt ein FluBdiagramm 230, welches die Schritte 
veranschaulicht, die der Installation einer Vorrichtungskon- 
figuration innerhalb einer Fieldbus-Vorrichtung zugeordnet 
sind. Ein Block 231 empfangt das Vorrichtungskonfigurati- 

25 ons-Installationsskript von der Workstation, konfiguriert 
durch das Kon figurations werkzeug, nachdem all die Verbin- 
dungs- und anderen Informationen fur diese Vorrichtung er- 
stellt worden sind. Ein Block 232 loscht dann die fruhere 
Konfiguration in der Vorrichtung, indem sie geeignete Be- 

30 fehle zu der Vorrichtung iiber die Schnittstellenkarte 40 sen- 
det. Wahrend es nicht strikt erforderlich ist, wurde es als 
wunschenswert gefunden, die fruhere Vorrichtungskonfigu- 
ration zu loschen, bevor versucht wird, eine neue Vorrich- 
tungskonfiguration in der Fieldbus-Vorrichtung zu installie- 

35 ren, um dadurch Installationsprobleme zu vermeiden. 

Ein Block 233 installiert dann die VCRs und ein Block 
234 installiert die Verbindungen, dae, erforderlich sind, um 
die Kommunikation gemaB dem verbindungsaktiven Plan 
und die Veroffentlicher/Teilnehmerbeziehungen, die fur das 

40 Fieldbus-Netzwerk erstellt wurden, zu implementieren. Ein 
Block 235 installiert dann die Fieldbus-Startliste in der Vor- 
richtung, was die Funktionsblock-Programmausfuhrung 
^ von dieser Vorrichtung mit der Programmausfuhrungen von 
anderen Funktionsblocken in anderen Vorrichtungen des 

45 Fieldbus-Netzwerks synchronisiert. Danach installiert ein 
Block 236 den Makrozyklus der Vorrichtung, nachdem die- 
ser Makrozyklus berechnet worden ist oder bestimmte wor- 
den ist, um all den synchronen Kommunikationen Rech- 
nung zu tragen, die zwangs weise iiber den Bus 42 stattfin- 

50 den miissen, welcher dem Fieldbus zugeordnet ist. 

Fig. 10 zeigt ein FluBdiagramm 240, welches die Schritte 
veranschaulicht, die dazu verwendet werden, um einen spe- 
ziellen oder bestimmten Funktionsblock innerhalb einer be- 
stimmten Vorrichtung innerhalb des Fieldbus-Netzwerks zu 

55 erstellen. Ein Block 241 empfangt zuerst ein Funktions- 
biock-Installationsskript, wie es durch das Konfigurations- 
werkzeug entwickelt wurde. Ein Block 242 installiert dann 
den nachsten Funktionsblock und Prograrnmausfuhrungspe- 
riodenparameter, wie dies in typischer Weise vorgenommen 

60 wird, wenn ein Fieldbus-Funktionsblock konfiguriert wird; 
Danach setzt ein Block 243 den Funktionsblockmodus au- 
Ber Service, was erforderlich ist, um die Werte innerhalb des 
Funktionsblockes zu andern. Ein Block 244 installiert dann 
die gemaB dem Funktionsblockparameter konfigurierten 

65 Werte oder die Anwenderprioritaten (overrides) (das heiBt 
die anwenderdefinierten Werte) innerhalb des Funktions- 
blockes. Diese durch den Anwender konfigurierten Werte; 
! konnen in irgendeiner Weise erstellt werden, wie beispiels- 
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weise durch die Verwendung von Dialogboxen in der Work- 
station wahrend der Konfiguration des ProzeBregelsy stems. 
Danach stellt ein Block 245 den Funktionsblockrnodus auf 
den konfigurierten Wert ein, so daB der Funktionsblock in 
Einklang mit der Art arbeitet, in welcher dieser konfiguriert 
ist. 

Es sei darauf hingewiesen, daB die FluBdiagramme der 
Fig. 7-9 lediglich die normalen Schritte angeben, die dazu 
verwendet werden, um ein Fieldbus-Netzwerk zu konfigu- 
rieren. In diesem Fall tragt jedoch die Erstellung des Field- 
bus-Netzwerks Rechnung hinsichtlich der und enthalt die 
Veroffentlicher/Teilnehmerverbindungen und VCRs, die er- 
forderlich sind, um den Betrieb von irgendeinem der Schat- 
tenfunktionsblocke iiinerhalb des Kontrollers 12 zu unter- 
stutzen. Naturlich kann die Anwenderworkstation oder der 
Kontroller 12 das Fieldbus-Netzwerk automatisch konfigu- 
rieren, basierend auf den Informationen, die durch den An- 
wender iiber die Erstellung des Regelsystems wahrend der 
Konfiguration dieses Systems geliefert werden. 

GemaB Fig., 11 veranschaulicht ein RuBdUagramm 250 
die Betrieb s weise eines Schattenfunktionsblockes, wenn ein 
Steuermodul, der diesen Schattenfunktionsblock enthalt, auf 
dem Kontroller 12 lauft, um die ProzeBsteuerung oder -rege- 
lung durchzufuhren. Wie zu erkennen ist, implementiert der 
Kontroller 12 die Blocke innerhalb eines bestimmten Mo 
duls (wie beispielsweise die Blocke 102, 104, 106 und 108 
von Fig. 4) in der Modulabtastrate, die dem Modul zugeord- 
net ist. Die Kommunikation von' verketteten Daten (wie den- 
jenigen, die durch die Verbindungen in dem Diagramm von 
Fig. 4 definiert sind) zwischen den aktuellen Fieldbus-Funk- 
tionsblocken und den Schattenfunktionsblocken erfolgt in 
der synchronen Makrozyklusrate des Fieldbus-Netzwerks, 
die verschieden sein kanii von der Modulabtastrate des Kon- 
trollers .12. Als ein Ergebnis werden die Daten fur die ver- 
ketteten Parameter in typischer Weise in der unteren Daten- 
bank 156 des Kontrollers 12 in einer unterschiedlichen (ge- 
wohnlich schnelleren) Rate als die Daten fur nicht verkettete 
Parameter gespeichert. 

Wenn der Schattenfunktionsblock in dem Kontroller 12 
implementiert ist, tastet ein Block 252 die Betriebsdaten ab, 
die innerhalb der unteren Datenbank 156 des Kontrollers 12 
gespeichert sind. Das heiBt, es werden wahrend jeder Mo- 
dulperiode die Betriebsdaten, die in der unteren Datenbank 
156 gespeichert wurden, durch den Schnittstellenmodul 40 
gelesen. Ein Block 254 ermittelt, ob die Abtastung voran- 
schreitet. Wenn dies nicht der Fall ist, erneuert ein Block 
256 den Blockfehler in dem Schattenfunktionsblock, stellt 
den Schattenfunktionsblock-Ausgangsstatus auf schlecht 
ein und stellt die Port-Integritat so ein, um dem Kontroller 
12 anzuzeigen, daB der Schattenfunktionsblock ausgefallen 
ist und daB daher ein Problem in bezug auf den externen 
Funktionsblock. oder in bezug auf Nachrichteniibertragun- 
gen mit dem externen Funktionsblock innerhalb des Field- 
bus-Netzwerks auftreten kann. Wenn solch ein Fehler detek- 
tiert wird, werden die Schattenfunktionsblockdaten nicht er- 
neuert (da diese Daten alt sind oder in jedem Fall schlechte 
Daten sind) und es wird die Emeuerungsoperation der Daten 
innerhalb des Schattenfunktionsblocks fur diesen Modulab- 
tastzyklus angehalten. Wenn jedoch die Abtastung voran- 
schreitet, kopiert ein Block 258 die empfangenen Betriebs- 
daten in dem Schattenfunktionsblock. Naturlich enthalten 
die Betriebsdaten nicht nur die Daten, die durch die Betrach- 
tungs- und Warnobjekte in der Modulabtastrate erhalten 
werden, sondern auch die Daten fur die verketteten Parame- 
ter, die erhalten wurden und in die untere Datenbank 156 in 
einer Rate eingeschrieben werden, die durch den Makrozy- 
• klus des Fieldbus-Netzwerks festgelegt wird. 

Ein Block 260 ermittelt dann, ob der statistische Revisi- 



onsparameter, der dem tatsachlichen Funktionsblock zuge- 
ordnet ist (der durch die Betrachtungsobjektoperauon gelie- 
fert wird) zugenommen hat. Wenn dies der Fall ist, instruiert 
ein Block 252 die Schnittstellenkarte 40, die statischen Da- 

5 ten, die dem Fieldbus-Funktionsblock zugeordnet sind, zu 
lesen und diese statischen Daten zu der unteren Datenbank 
156 zu liefem, wo diese Daten gelesen werden und in den 
Schattenfunktionsblock eingesetzt werden. Wie dies be- 
kannt ist, zeigt der statische Visionsparameter an, ob irgend- 

10 welche statischen Daten, die normalerweise durch die stati- 
sche Betrachtungsliste vorgesehen werden, geandert wur- 
den. Wenn der statische Revisionsparameter nicht erhoht 
wurde, werden keine der statischen Daten geandert und es 
ist nicht erforderlich, diese Daten wahrend jedes Zyklusses 

15 des Steuermoduls zu lesen. Wenn jedoch die statische Da- 
tenrevision zugenommen hat, dann haben sich einige der 
statischen Daten geandert und es mussen diese statischen 
Daten gelesen werden und in den Schattenfunktionsblock 
gesetzt werden, so daB der Schattenfunktionsblock die Da- 

20 ten spiegelt, die tatsachlich innerhalb des externen Funk- 
tionsblocks vorhanden sind. 

Nachdem die statischen Daten erhalten worden sind oder 
die statische Revision nicht zugenommen hat, bildet ein , 
Block 264 die ; Fieldbus-Alarme (und andere Daten, wenn 

25 dies erforderlich ist) in den Alarmen (oder anderen Datenbe-r 
reichen) des Kontrollers 12 ab. Diese Abbildung kann unter 
Verwendung einer Nachschlagetabelle erreicht werden oder 
durch irgendeine andere Abbildungstechnik. Die abgebilde- 
ten AlarmgroBen (und andere Daten) werden dann in dem 

30 Schattenfunktionsblock gespeichert, um durch andere Steu- 
erblocke des Steuermoduls verwendet zu werden. Die 
AlarmgroBen konnen auch fur einen Anwender dargestellt 
werden oder in irgendeiner anderen gewiinschten Weise ver- 
wendet werden. 

35 Danach ermittelt ein Block 266, ob die Daten fur die ver- 
ketteten Parameter veraltet sind (das heiBt nicht mehr aktu- 
ell sirid). Solch eine Anzeige wird in regularer Weise in den 
Fieldbus-Kommunikationen erzeugt und sie zeigt an, daB 
die empfangenen Daten nicht in dem allerletzten Makrozy- 

40 klus des Fieldbus-Netzwerks erzeugt wurden, was anzeigen 
kann, daB ein Zeitsteuerproblem oder ein anderes Problem 
innerhalb des Fieldbus-Netzwerks existieren kann. Wenn 
die Verkettungsparameterdaten veraltet sind, markiert ein 
Block 268 die Ausgangsdaten als BadNotConnected, was 

45 den Modus oder Status von anderen Funktionsblocken in- 
nerhalb des Kontrollers 12 andern kann. Danach oder wenn 
die verketteten Daten nicht veraltet sind, macht ein Block 
270 die Betriebsdaten ftir andere Blocke innerhalb des Kon- 
trollers 12 sichtbar und der Kontroller 12 fahrt damit fort, 

50 basierend auf den neuen Betriebsdaten zu arbeiten. 

Wie ersehen werden kann, veranschaulicht das FluBdia- 
gramm von Fig. 11 die Betriebs weise der Erneuerung des 
Schattenfunktionsblocks, um sicherzustellen, daB dieser die 
Daten spiegelt, die dem externen Funktionsblock innerhalb 

55 einer externen Vorrichtung zugeordnet sind. Jedoch kann 
der Schattenfunktionsblock auch Daten zu dem externen 
Funktionsblock iibertragen und Schreibbefehle an den exter- 
nen Funktionsblock senden. Solche Daten und Schreibbe- 
fehle konnen von einem Anwender, beispielsweise bei einer 

60 Workstation, vorgesehen werden oder konnen an anderen 
Funktionsblocken innerhalb des Kontrollers 12 entspringen 
und von diesen ausgesendet werden, und zwar iiber die er- 
stellten Verbindungen. GemaB Fig. 12 veranschaulicht ein 
RuBdiagramm 280 die Schritte, die unternommen werden, 

65 um Daten oder Schreibbefehle zu einem extemen Funk- 
tionsblock uber den Schattenfunktionsblock zu senden. Bei 
einem Block 281 schreibt ein Steuerblock innerhalb des 
Kontrollers 12 Daten uber eine Eingangsvefbindung in den 
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Schattenfuiiktionsblock ein. Alternativ kann ein Anwender 
einen Schreibbefehl an den Schattenfunktionsblock iiber 
eine Anwenderschnittstelle senden, was es einem Anwender 
ermoglicht, z. B. von Hand einen SoUwert oder einen ande- 
ren Wert, der dem externen Funktionsblock zugeordnet ist, 5 
zu andern. Der Schattenfunktionsblock sendet dann unrnit- 
telbar einen Schreibbefehl oder andere Daten an die Schnitt- 
stellenkarte 40. Wenn solche Daten oder Befehl einem ver- 
ketteten Parameter zugeordnet sind oder ist, veroffentlicht 
die Schnittstellenkarte 40 die Daten auf dem Fieldbus-Bus 10 
fur den externen Funktionsblock zu einem geeigneten oder 
synchronen Zeitpunkt, wie dieser durch den Makrozyklus 
des Fieldbus-Netzwerks festgelegt ist. Wenn der Schreibbe- 
fehl oder die Daten nicht einem verketteten Parameter zuge- 
ordnet ist bzw. sind, verwendet die Schnittstellenkarte 40 15 
asynchrone Nachrichtenubertragungen, um den Befehl oder 
die Daten an den externen Funktionsblock zu ubermitteln. 
Danach empfangt der externe Funktionsblock die Daten 
oder den Befehl und erneut deren oder dessen Attributpara- 
meter entsprechend. Diese Anderungen werden dann iiber 20 
die Schnittstellenkarte 40 unter Verwendung von Veroffent- 
licher/Teilnehmer-Kommunikationen zuruck iibertragen, als 
auch die Betrachtungsobjektoperation, und es werden die 
neuen Daten in die untere Datenbank 156 gesetzt, wo dann 
wahrend des nachsten Abtastzyklusses des Steuermoduls 25 
diese Daten in den Schattenfunktionsblock eingesetzt wer- 
den. 

Wenn der Block 282 eine Schreibanfrage an die Schnitt- 
stellenkarte 40 sendet und diese Anfrage zu dem externen 
Funktionsblock gesendet wird, empfangt die Schnittstellen- 30 
karte 40 eine Antwort von dem Funktionsblock, die anzeigt, 
ob der. Schreibvorgang vervollstandigt worden ist oder ob 
die Daten angenommen oder empfangen wurden. Die 
Schnittstellenkarte 40 sendet ihrerseits diese Antwort zu 
dem Schattenfunktionsblock. Wenn der Schreibvorgang 35 
fehlgeschlagen ist, kann die Status-, Alarm- oder Fehlerein- 
stellung des Schattenfunktionsblocks geandert werden, urn 
diesen Fehler zu reflektieren. Wenn beispielsweise eine . 
Schreibanfrage, die einem verketteten Parameter zugeordnet 
ist, nicht empfangen wurde oder nicht richtig durch die 40 
Schnittstelle 40 implementiert wurde, kann dies in dem Feh- 
lerstatus des Schattenfunktionsblocks angezeigt werden. 
Wenn es gewiinscht wird, wenn eiri Schreibbefehl, der von 
einem Anwender stammt, fehlschlagt, implementiert zu 
werden, kann ein Block 283 eine Anzeige iiber den Fehl- 45 
schlag fur den Anwender bei der Workstation senden oder 
zu irgendeiner anderen Anwenderschnittstelle, um dadurch 
den Anwender uber den fehlgeschlagenen Versuch zu unter- 
richten, in den externen Funktionsblock zu schreiben. 

Wahrend sich die Beschreibung auf die Implementierung 50 
und die Verwendung eines einzelnen Schattenfunktions- 
blockes 108 gerichtet hat, sei darauf hingewiesen, daB viele 
Schattenfunktionsblocke in dem gleichen Steuermodul oder 
Kontroller implementiert werden konnen, um es dem Steu- 
ermodul oder Kontroller zu ermoglichen, viele exteme 55 
Funktionsblocke zu verwenden. Ferner konnen Schatten- 
funktionsblocke implementiert werden unter Verwendung 
irgendeines externen ProzeBsteuer- oder -regel-Kommuni- 
kationsprotokolls (neben dem Fieldbus-Protokoll) und konr 
nen dazu verwendet werden, mit irgendeiriem Typ eines 60 
Funktionsblocks zu korhmunizieren, inklusive irgendeinem 
Funktionsblock, der ahnlich ist mit oder der gleiche ist wie 
irgendeiner der unterschiedlichen Funktionsblocke, die . 
durch das Fieldbus-Protokoll spezifisch identifiziert und un- 
terstutzt werden. Obwohl dariiber hinaus Schattenfunktions- 65 
blocke hier so beschrieben wurden, als ob sie einem exter- 
nen Funktionsblock zugeordnet sind, und zwar in der Form, 
in welcher das Fieldbus-Protokoll einen "Funktionsblock" 
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definiert, sei darauf hingewiesen, daB die Verwendung des 
Ausdrucks "Funktionsblock" hier nicht auf das beschrankt 
ist, was das Fieldbus-Protokoll als einen Funktionsblock de- 
finiert, sondern statt dessen irgendein anderer Typ eines 
Blocks, Programms, einer Hardware, Firmware usw. enthal- 
ten ist, die mit irgendeinem Typ eines Steuersystems oder 
Regelsystems und/oder Kommunikationsprotokoll zugeord- 
net ist und die dazu verwendet werden kann, um eine ge- 
wisse Steuerfunktion oder Regelfunktion zu implementie- 
ren. Obwohl somit Funktionsblocke typisch die Form von 
Objekten annehmen, und zwar innerhalb einer objektorien- 
tierten Programmierumgebung, muB dies nicht der Fall sein 
und statt dessen konnen andere logische Einheiten dazu ver- 
wendet werden, um eine bestimmte Steuerung oder Rege- 
lung (inklusive Eingabe- und Ausgabe-)Funktionen inner- 
halb einer ProzeBsteuerumgebung oder ProzeBregelumge- 
bung auszufiihren. 

Obwohl ferner der Schattenfunktionsblock, der hier be- 
schrieben wurde, in bevorzugter Weise in einer Software 
implementiert wird, die beispielsweise in einem Kontroller 
oder einer anderen ProzeBsteuervorrichtung gespeichert ist, 
kann sie alternativ oder zusatzlich in einer Hardware, Firm- 
ware usw. in gewunschter Weise implementiert sein. Wenn 
sie in einer Software implementiert ist, kann der Schatten- 
funktionsblock der vorliegenden Erfindung in irgendeinem 
computerlesbaren Speicher gespeichert sein, wie beispiels- 
weise einer Magnetplatte, einer Laserplatte oder einem an- 
deren Speichermedium, in einem RAM oder ROM eines 
Computers usw.Tn ahnlicher Weise kann diese Software an 
einen Anwender oder eine Vorrichtung aus geliefert werden, 
und zwar iiber irgendein bekanntes oder-gewiinschtes Aus- 
lieferungsverfahren, inklusive beispielsweise iiber einen 
Nachrichtenubertragungskanal, wie beispielsweise eine Te- 
lefohleitung, das Internet usw. 

Obwohl auch der Schattenfunktionsblock der vorliegen- 
den Erfindung in Einzelheiten in Verbindung mit einem Pro- 
zeBregelnetzwerk beschrieben wurde, welches die ProzeB- 
steuerfunktionen in einer dezentralisierten oder verteilten 
Weise unter Verwendung eines Satzes von Fieldbus-Vor- 
richtungen implementiert, sei darauf hingewiesen, daB der 
Schattenfunktionsblock der vorliegenden Erfindung in Ver- 
bindung mit ProzeBregelnetzwerken verwendet werden 
kann, die Steuerfunktionen ausfuhren, unter Verwendung 
von anderen Typen von Bereichsvorrichtungen und Kom- 
munikationsprotokollen, inklusive der Protokolle, die auf 
anderen als den zwei Leitungsbussen basieren, und Proto- 
kollen, die analog und/oder digitale Nachrichtenubertragun- 
gen unterstutzen. Der Schattenfunktionsblock der vorliegen- 
den Erfindung kann beispielsweise in irgendeinem ProzeB- 
regelnetzwerk verwendet werden, welches Vorrichtungen 
verwendet, die in Einklang mit dem HART-, PROFEBUS-, 
usw. Kommunikationsprotokollen oder irgendeinem ande- 
ren Kommunikationsprotokoll stehen, die es nunmehr gibt 
oder die in der Zukunft entwickelt werden konnen. In ahnli- 
cher Weise kann, wenn dies gewiinscht wird, der Schatten- 
funktionsblock der vorliegenden Erfindung in ProzeBregel- 
netzwerken verwendet werden, die keine verteilten Steuer- 
funktionen haben, sondern statt dessen einen zentralisierten 
Kontroller oder ein Steuer- oder Regelschema verwenden, 
um die Vorrichtungen darin zu steuern oder zu regeln. 

Wahrend die vorliegende Erfindung in bezug auf spezifi- 
sche Beispiele beschrieben wurde, die dazu dienen, die Er- 
findung lediglich zu veranschaulichen, jedoch nicht einzu- 
schrankenj ist es fur Fachleute offensichtlich, daB Anderun- 
gen, Erganzungen oder Weglassungen bei den offenbarten 
Ausfuhrungsformen vorgenommen werden konnen, ohne 
dadurch die Idee und den Rahmen der vorliegenden Erfin- 
dung zu verlassen. 
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Patentanspriiche 

1. Interface-Funktionsblock fur die Verwendung in ei- 
nem ProzeGkontroller, der kommunikativ mit einer ex- 
temen Vorrichtung iiber ein Kommunikationsnetzwerk 5 
gekoppelt ist, wobei der ProzeGkontroller folgendes 
implementiert: 

- eine Steuerroutine unter Verwendung eines in- 
ternen Funktionsblockes, welcher innerhaib des 
ProzeBkontrollers angeordnet ist, und 10 

- einen externen Funktionsblock, der in der ex- 
ternen Vorrichtung angeordnet ist, wobei der In- 
terface-Funktionsblock folgendes aufweist: 

- einen Kommunikationsport mit einem Eingang, 
der mit dem externen Funktionsblock tiber das 15 
Kommunikationsnetzwerk kommuniziert, urn Da- 
ten, die den externen Funktionsblock betreffen, zu 
empfangen, und 

- einen Speicher, der die empfangenen Daten, die 
den externen Funktionsblock betreffen, gemaB ei- 20 
nem Kommunikationsprotokbll des internen . 
Funktionsblockes speichert. 

2. Interface-Funktionsblock nach Anspruch 1, der fer- 
ner einen Ausgang umf aBt, der die Daten, die den ex- 
ternen Funktionsblock betreffen, an den internen Funk- 25 
tionsblock gemaB dem Kommunikationsprotokoll des 
internen Funktionsblockes liefert. ' 

3. Interface-Funktionsblock nach Anspruch 2, bei dem 
der Eingang des Kommunikationsports die Daten, die 
den externen Funktionsblock betreffen, unabhangig 30 
von der Operation des internen Funktionsblockes emp-' 
fangt. 

4. Interface-Funktionsblock nach Anspruch 2, bei dem 
der externe Funktionsblock iiber das Kommunikations- 
netzwerk unter Verwendung eines ersten Kommunika- 35 
tionsprotokolls kommuniziert, welches verschieden ist 
von einem zweiten Kommunikationsprotokoll, das 
dem Konfigurationsprotokoll des internen Funktions^ 
blpckes zugeordnet ist und bei dem der Eingang des 
Kommunikationsports mit dem externen Funktions- 40 
block unter Verwendung des ersten Kommunikations- 
protokolls kommuniziert und der Ausgang mit dem in- 
ternen Funktionsblock gemafi dem zweiten Kommuni- 
kationsprotokoll kommuniziert. 

5. Interface-Funktionsblock nach Anspruch 4, bei dem 45 
das erste Kommunikationsprotokoll ein Fieldbus- 
Kommunikationsprotokoll ist und bei dem der Eingang 
des Kommunikationsports mit dem externen Funk- 
tionsblock unter Verwendung des Fieldbus-Kommuni- 
kationsprotokolls kommuniziert. 50 

6. Interface-Funktionsblock nach Anspruch 5, bei dem 
der Eingang des Kommunikationsports eine Schnitt- 
stellenvorrichtung verwendet, die konfiguriert ist, um 
mit der externen Vorrichtung unter Verwendung des 
Fieldbus-Kommunikationsprotokolls zu kommunizie- 55 
ren, um mit dem externen Funktionsblock zu kommu- 
nizieren. 

7. Interface-Funktionsblock nach Anspruch 1, bei dem 
der Kommunikationsport mit dem externen Funktions- 
block unter Verwendung synchroner Nachrichteniiber- 60 
tragungen kommuniziert. 

8. Interface-Funktionsblock nach Anspruch 1, bei dem 
- der Kommunikationsport mit dem externen Funktions- 
block unter Verwendung synchroner und asynchroner 
Nachrichtenubertragungen kommuniziert. 65 

9. Interface-Funktionsblock nach Anspruch 1, bei dem 
die externe Vorrichtung unter Verwendung eines Vor- 
richtungskommunikationsprotokolls Nachrichten iiber- 



0 A.l 

38 

mittelt, welches die Kommunikation von logisch ver- 
ketteten Paketen vori Daten unter Verwendung von 
standardisierten Kommunikationsanrufen unterstiitzt 
und bei dem der Kommunikationsport mit dem exter- 
nen Funktionsblock unter Verwendung der standardi- 
sierten Kommunikationsanrufe kommuniziert, die dem 
Vorrichtungskommunikationsprotokoll zugeordnet 
sind. 

10. Interface-Funktionsblock nach Anspruch 9, bei 
dem das Vorrichtungskommunikationsprotokoll ein 
Fieldbus-Kommunikationsprotokoll ist und bei dem 
der Kommunikationsport mit der externen Vorrichtung 
unter Verwendung von Betrachtungsobjekten innerhaib 
des Fieldbus-Kornmunikationsprotokolls kommuni- 
ziert. 

11. Interface-Funktionsblock nach Anspruch 1, bei 
"dem der Kommunikationsport eine Alarmanzeige von 
dem externen Funktionsblock empfangt und bei dem 
der Speicher die empfangene Alarmanzeige speichert. . 

12. Interface-Funktionsblock nach Anspruch 1, bei 
dem der Kommunikationsport ferner einen Ausgang 
enthalt, welcher Daten zu dem externen Funktions- 
block unter Verwendung eines Kommunikationsproto- 
kolls sendet, welches dem extemen Funktionsblock zu- 
geordnet ist. 

1 3 . Kontroller, der dafur ausgebildet ist, um kommuni- 
kativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, wobei eine der Bereichsvorrichtun- 
gen einen extemen Funktionsblock enthalt, der unter 
Verwendung eines Vorrichtungskommunikationsproto- 
kolls Nachricht iibertragt, wobei der Kontroller folgen- 
des aufweist: 

einen Prozessor; 
einen Speicher; und 

eine Steuerroutine, die in dem Speicher gespeichert ist 
und durch den Prozessor implementiert wird, um die 
Vielzahl der Bereichsvorrichtungen zu steuem, wobei 
die Steuerroutine folgendes enthalt: 

- eine Vielzahl von miteinander verbundenen in- 
ternen Funktionsblocken, die so konfiguriert sind, 
um" ein Kontrollerprotokoll zu verwenden und 
durch den Kontroller implementiert sind, und 

- einen Interface-Funktionsblock, der mit einer 
der Vielzahl der miteinander verbundenen inter- 
nen Funktionsblocke unter Verwendung des Kon- 
trollerprotokolls kommuniziert, und der mit dem 
externen Funktionsblock innerhaib einer der Be- 
reichsvorrichtungen unter Verwendung des Vor- 
richtungskommunikationsprotokolls kommuni- 
ziert, wobei der Interface-Funktionsblock Daten 
speichert, die den externen Funktionsblock betref- 
fen, welche von dem externen Funktionsblock 
empfangen wurden. 

14. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock die Daten, die den extemen Funk- 
tionsblock betreffen, unabhangig von der Operation 
der Vielzahl der internen Funktionsblocke empfangt. 

15. Kontroller nach Anspruch 13, bei dem das Vor- 
richtungskommunikationsprotokoll ein Fieldbus-Kom- 
munikationsprotokoll ist und bei dem der Interface- 
Funktionsblock mit dem extemen Funktionsblock un- 
ter Verwendung des Fieldbus-Kommunikationsproto- 
koUs kommuniziert. 

16. Kontroller nach Anspruch 15, bei dem der Inter- 
face-Funktionsblock mit dem externen Funktionsblock 
unter Verwendung von Betrachtungsobjekten innerhaib 
des Fieldbus-Kommunikationsprotokolls kommuni- 
ziert. 
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17. Kontroller nach Anspruch 15, bei dem der Inter- 
face-Funktionsblock mit dem externen Funktionsblock 
unter Verwendung von Teilnehmer /Herausgeber- 
Nachrichtenubertragungen innerhalb des Fieldbus- 
Konmiunikationsprotokolls kommuniziert. . 5 

18. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, welche die Eingangsgro- 
8en und AusgangsgroBen des externen Funktionsblok- 
kes betreffen, empfangt und speichert. 

19. Kontroller nach Anspruch 13, bei dem der Inter- 10 
face-Funktionsblock Daten, die AlarmgroBen betref- 
fen, welche durch den externen Funktionsblock erzeugt 
warden, empfangt und speichert. 

20. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, die den Modus des exter- 15 
nen Funktionsblockes betreffen, empfangt und spei- 
chert. 

21. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, die durch eine der Vielzahl 
der intemen Funktionsbldcke erzeugt wurden, zu dem 20 
externen Funktionsblock sendet. 

22. Kontroller nach Anspruch 13, bei dem der Inter- 
f ace-Funktionsblock einen Befehl, der durch den Kon- 
troller erzeugt wurde, zu dem externen Funktionsblock 
sendet. ■ 25 

23. Verfahren zum Implementieren einer Steuer- oder 
Regelroutine in einem ProzeBkontroller, der kommuni^ 
kativ mit einer Bereichsvorrichtung gekoppelt ist, wo- 
bei die Bereichsvorrichtung einen externen Funktions- 
block aufweist, der in ihr angeordnet ist und unter Ver- 30 
wendung eines Vorrichtungskommunikationsproto- 

. kolls Nachrichten ubertragt, wobei das Verfahren die 
folgenden Schritte umfafit: 

- Speichern einer Vielzahl von miteinander ver- 
bundenen ihternen Funktionsblocken in dem Kon- 35. 
troller, der gernaB einem Kontrollerprotokoll kon- 
figuriert ist, um diese als Teil der Steuer- oder Re- 
gelroutine zu implementieren; 

- Erzeugen eines Interface-Funktionsblockes in- 
nerhalb des ^Controllers, der gemaB dem Kontrol- 40 

' lerprotokoll konfiguriert ist, wobei der Interface- 
Funktionsblock mit dem externen Funktionsblock 
unter Verwendung des Vorrichtungskommunikati- 
onsprotokolls kommuniziert; 

- Erzeugen einer Steuer- oder Regelroutine, wel- 45 
che die Vielzahl der miteinander verbundenen in- 
ternen Funktionsblocke und den Interface-Funk- 
tionsblock verwendet, um den ProzeB zu steuern 
oder zu regeln; und 

- Speichern von Daten in dem Interface-Funk- 50 
tionsblqck waWend der Implementierung der 
Steuer- oder Regelroutine, die dem externen 
Funktionsblock zugeordnet sind und von diesem 
empfangen werden. 

24. Verfahren nach Anspruch 23, welches femer den 55 
Sehritt der Verwendung des Interface-Funktionsblok- 
kes fur eine Kommunikation mit dem externen Funk- 
tionsblock aufweist, um Daten, die dem externen Funk- 
tionsblock zugeordnet sind, unabhangig von der Ope- 
ration der intemen Funktionsblocke zu erneuern. 60 

25. Verfahren nach Anspruch 23, welches ferner den 
Sehritt einer Verwendung des Interface-Funktionsblok- 
kes umfaBt, um weitere Daten zu dem externen Funk- 
tionsblock zu ubertragen, um die Konfiguration des ex- 
ternen Funktionsblockes zu andern. 65 

26. Verfahren nach Anspruch 23, welches ferner fol- 
gende Schritte enthalt: 

- einem Anwender erlauben, die Steuer- oder Re- 
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gelroutine dadurch zu konfigurieren, indem jeder 
eine Anzahl von Funktionsblocken, die in der 
Steuer- oder Regelroutine zu verwenden sind, 
spezifiziert wird, 

- die Verbindungen zwischen den spezifizierten 
Funktionsblocken, die in der Steuer- oder Regel- 
routine zu verwenden sind, zu identifizieren, und 

- die Lage eines bestimmten spezifizierten Funk- 
tionsblockes als einen internen Funktionsblock zu 
spezifizieren, der in dem Kontroller implementiert 
ist, oder als externen Funktionsblock zu spezifi- 
zieren, der durch die Bereichsvorrichtung imple- 
mentiert ist. . 1 

27. Verfahren nach Anspruch 26, bei dem der Sehritt 
der Spezifizierung der Lage des bestimmten spezifi- 
zierten Funktionsblockes als den externen Funktions- 
block den folgenden Sehritt aufweist: 

- Auswahlen einer, externen Vorrichtung, in wel- 
cher der exteme Funktionsblock zu implementie- 
ren ist, aus einer Liste von externen Vorrichtun- 
gen, die an den Kontroller angeschlossen sind. 

28. Verfahren nach Anspruch 23, bei dem der Sehritt 
der Speicherung der Daten, die dem externen Funk- 
tionsblock zugeordnet sind, den folgenden Sehritt auf- 
weist: 

- Speichern einer Alarmanzeige, die durch den 
externen Funktionsblock in dem Interface-Funk- 
tionsblock erzeugt wird, 

und bei dem das Verfahren des weiteren folgenden 
Sehritt aufweist: 

- Verwendung der Aiarmanzeige, die in dem In- 
terface-Funktionsblock gespeichert ist, zum Trig- 
gern einer Alarmverarbeitung innerhalb des Kon- 
trollers. 

29. Verfahren nach Anspruch 23, welches ferner den 
folgenden Sehritt aufweist: 

- Darstellung der Steuer- oder Regelroutine 
durch Darstellen einer Wiedergabe der internen 
Funktionsblocke, einer Wiedergabe des Interface- 
Funktionsblocks und von Wiedergaben der Ver- 
bindungen zwischen den internen Funktionsblok- 
ken und den Interface-Funktionsblocken, so daB 
der Interface-Funktionsblock den externen Funk- 
tionsblock reprasentiert. 
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